中級Git操作
今回の記事の内容はGitHub共同創業者のScott Chacon氏の「Pro Git」と同氏の今年の「So You Think You Know Git」（Gitがわかっているとでも思っているか？）発表をベースにしている。 コンフィグ ここでコンフィグにてデフォルトとして指定して損がないオプションをいくつか紹介します。 git rerere git rerereは"reuse recorded resolution"（記録ずみ解決方法を再利用）の略語になっている。 名の通りマージコンフリクトがどう解消されたかを記録し、次に同じようなコンフリクトが発生した際、同様の解決方法を自動的に適用するためのコマンドです。 また、基本的にデフォルトにしてもときに差し支えないため、ぜひgit config --global rerere.enabled trueを実行してみてください。 git main
VSCodeでGitのコミットを楽に整理して、レビュワーに「コイツできる」と思わせよう。
はじめに Git Graphという拡張機能を使います。 Git GraphとGitLensという拡張機能を使います。[1] また、gitから開かれるエディタをvscodeにしておきます。 コミットのまとめかた（1分未満でできるよ） ステータスバーのGit Graphのボタンをクリックして、Git Graphの画面を開きます。 まとめたいコミットの一つ前のコミット（今回だとinit）を右クリックして、「Rebase current branch on this Commit...」を選択します。 「Launch Interactive Rebase in new Terminal」にチェックを入れて「Yes, rebase」をクリックします。 こんな画面が開きます。 まとめたいコミットを上から順にpickからsquashに変更します。最後の一つはpickのままにしておきます。そして「STAR
2024年Gitワークフロー再考 | フューチャー技術ブログ
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
VScodeだけでGit操作を完結させるのだ～～ッ!!
VScodeだけでGit操作を完結させる方法について書くのだ。 👀その前に！ この記事は、以下の2つの拡張機能がインストールされている前提で進めるのだ。 Git Graph - Visual Studio Marketplace GitLens — Git supercharged - Visual Studio Marketplace インストールしておいてほしいのだ。 ✅ステージング(git add ◯） 以下のようにするのだ。 ＋ボタンをクリック：ステージングする ーボタンをクリック：ステージングを解除する ▲ステージング→解除 ✅コミット名を自動でつける 右にある✨ボタンを押すと、コミット名を自動で決めてくれるのだ👇 ▲この例だと、変更内容が意味不明すぎて変なコミット名になってるし、現状英語だけみたい？ これは、GitHub Copilotの機能なのだ。 ✅コミット(git c
Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
GitHub - dahlbyk/posh-git: A PowerShell environment for Git
posh-git Table of contents: Overview Versions Installation Using posh-git Git status summary information Customization variables Customizing the posh-git prompt Based on work by Overview posh-git is a PowerShell module that integrates Git and PowerShell by providing Git status summary information that can be displayed in the PowerShell prompt, e.g.: posh-git also provides tab completion support fo
Gitでブランチの派生元を間違えたときの解決方法（rebase --onto、cherry-pick） | 株式会社グランフェアズ
Gitでブランチの派生元を間違えたときの解決方法（rebase --onto、cherry-pick） Posted by NAGAYA on Jan 31st, 2019 Gitを使って複数人で開発を行う場合、自分の作業用に「ブランチ」を作る機会が多いと思います。 Git初心者の人であっても、はじめの方に触れる工程のひとつですよね。グランフェアズではブランチ作成のコマンドを次のように教えています。 $ git checkout -b {作成するブランチ名} {親にするブランチ名} ところが、この{親にするブランチ名}が正しく指定されない（=ブランチの派生元を間違える）と後々問題になってしまうことも…。実際にどんなことがあったのか、事例をもとに見ていきましょう。 「ブランチの派生元を間違える」とは 派生元の間違い方として思いつくのはこんなところでしょうか。 親にするブランチが古かった（ブラ
Bitbucket の Git LFS でバイナリファイルをバージョン管理する
こんにちは。これを読んでいる方の中には、設計書などのドキュメントをExcelファイルで作成していたり、成果物と呼ぶファイルをソースコードと一緒にバージョン管理をしている（したい）方がいらっしゃるかと思います。このブログでは、そのようなお客様からよく質問される Git LFS についてご紹介します。 Git で バイナリファイル や 大容量のファイル を取り扱うときに困る事 Bitbucket のお問合せも増えてきて、改めて Git の導入を検討しているユーザーが増えてきているなと実感しています。それと同時に様々なご相談を頂くことも増えました。その中でも特に頂くご相談の一つに「Gitで成果物も管理してトレーサビリティを向上させたい。」というご要望があります。 ここで言う成果物とは「Excelなどで作成した設計書などのドキュメント」「VisioやCADといった作図ツールで出力した図面ファイル」
大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
git commit --fixup と git rebase --autosquash で簡単に commit が整理できて感動した話
git commit --fixup と git rebase --autosquash で簡単に commit が整理できて感動した話 Written by @ryysud Apr 2, 2019 00:07 · 2636 words · 6 minutes read #git よくある面倒なシチュエーション PR を作成した際に、開発中にメインとなる実装の commit とは別に、レビューを受けての修正であったり、ちょっとしたリファクタリングであったり、typo 修正などの細かな commit を、PR の中で粛々と対応するシチュエーションは、どなたにも経験があることだと思います。そして、マージ前に git rebase -i を使って commit を整理するにしても、エディタを開き、どれがどれに紐付く commit なのかをマッピングするのは非常に面倒な作業だと思います。 そこで今
容量の大きいリポジトリを必要最低限の情報だけ clone する方法 - Qiita
はじめに git リポジトリは歴史を重ねるごとに、だんだんと容量がおおきくなっていしまい、しまいにはギガ単位になってしまう事ってありますよね。 自分も、とあるリポジトリを clone したら、なんとgitの容量が数十ギガに達していて、PCのローカルストレージが圧迫されてしまう問題にあってしまったので、その時の対応方法を備忘録として残しておきます。 容量を調べる どれくらいの容量なのか調べるには du コマンドを使います。 55Gもあります。 泣けてきます。 ダウンロードにも1時間くらいかかります... 解決方法 今回行った解決方法としては、下記のような対策をとりました。 直近の歴史だけを取得する 必要なブランチを1つだけを取得する 直近の歴史だけを取得する depth オプション 今回は特に修正歴史は必要ないと判断した為、直近の修正記録だけを取得するようにして、容量削減を行いました。 de
入門書を終えた人に捧げる、社会人のためのGit中級編 - Qiita
自分が実際に企業で働くうえでよく使ったコマンドや役に立った設定をまとめてみました。 Git入門系に関しては飽和していると思いますが、ちょっとした応用編としてご覧いただければ幸いです。 自分の環境 ファイルの数や行数が膨大 複数の案件が同時進行することが多く、質問などに答えたりするためにブランチ移動をすることが多い プロジェクト内に複数文字コードが混在している（Shift-JISとUTF-8） コマンド編 基本のコマンド書きなぐり $ git clone <ブランチ名> <ディレクトリ名> # clone先のディレクトリ名まで指定してcloneする $ git pull # pullする。必要に応じて -u や、 remote名、ブランチ名を打ち込む $ git diff # 差分見る $ git diff master HEAD # 現在の状態とmasterを比較する $ git chec
Set the default branch for newly-created repositories
August 26, 2020 You can now set the default branch name for newly-created repositories under your username. This setting does not impact any of your existing repositories. Existing repositories will continue to have the same default branch they have now. Organization and enterprise administrators can also set the default branch name for new repositories created in their organization or enterprise.
Git レビューする時に使うコマンド - Qiita
目的 タスクの作業途中にレビュー依頼を受けた時のコマンドをまとめました。 深夜テンションで書いたのでおかしいところがあったらコメントにて教えてください🙏 環境
ルークよ git push --force を使わないでおくれ… git push --force-with-lease を使っておくれ… - Qiita
ルークよ git push --force を使わないでおくれ… git push --force-with-lease を使っておくれ…Git まとめ git push --force ではなく git push --force-with-lease を使おう --force-with-lease オプション付き push を alias 登録しておくと便利 そもそも git push --force とは git push --force は強制pushのためのコマンド。いったんリモートにpushしたコミットを なかったことにする 場合に使われる。たとえば、次のような場合: 間違ってpushされたコミットを、リモートのlogから消し去る場合 GitHub Actions動作確認用にpushされた実験的なコミットを、あとで消す場合 --force-with-lease を使おう 過ちを正
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What's new in 2.0.0? 🆕 | git-cliff
Gitlab : Peer's certificate issuer has been marked as not trusted by the user
mrkmyki.com
Git 現在のブランチを名前指定せずにpushする - Qiita
.github/CODEOWNERSをつくるだけでレビュワー設定に疲弊しなくなるのでオススメ - Qiita
