Git フォーク と アップストリーム：仕組みと役に立つヒント
Nicola Paolucci
開発者アドボケート
プロジェクトをフォークして独自の変更を加えると、自分の貢献を簡単に統合できます。しかし、これらの変更をアップストリームに戻すこと (つまり、親リポジトリに返送すること) をしない場合、変更を追跡できなくなり、自分のリポジトリに分岐行が発生するおそれがあります。すべての貢献者が同じ場所から行を作成していることを確認するには、git のフォークと git upstream の相互作用に関する原則をいくつか知っておく必要があります。このブログでは、基本事項、落とし穴を紹介し、時代を先取りするための役に立つヒントも紹介します。
Git upstream: 最新の状態を維持して貢献する
まず、一般的なセットアップおよび upstream リポジトリとやりとりするための最も基本的なワークフローについて、詳しく説明します。
標準的なセットアップでは、通常 origin と upstream remote が作成されています。後者はプロジェクトのゲートキーパー、または貢献先となる信頼できる情報源です。
まず、upstream リポジトリ用のリモートと、できれば origin も既にセットアップしてあることを確認します。
git remote -v
origin git@bitbucket.org:my-user/some-project.git (fetch)
origin git@bitbucket.org:my-user/some-project.git (push)upstream のセットアップがまだの場合、remote コマンドを使用するだけで簡単に追加できます。
git remote add upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git
関連資料
Git リポジトリ全体を移動する方法
ソリューションを見る
Bitbucket Cloud での Git の使用方法についてのチュートリアルです。
リモートが正しく追加されたか確認します。
git remote -v
origin git@bitbucket.org:my-user/some-project.git (fetch)
origin git@bitbucket.org:my-user/some-project.git (push)
upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (fetch)
upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (push)これで、fetch することにより、upstream リポジトリの最新の変更をまとめて収集できます。更新を入手するたびに、これを繰り返します。
(main にマージされていないタグがプロジェクトに含まれている場合は、git fetch upstream --tags コマンドも実行すべきです)
git fetch upstream一般的には、ローカルの master ブランチを upstream main の近似ミラーとして保持し、フィーチャー ブランチで任意の作業を行います。なぜなら、これらが後でプル リクエストになる可能性があるからです。
この時点で、merge を使用しても rebase を使用しても、結果は通常同じです。ここでは merge を使用しましょう。
git checkout main
git merge upstream/mainupstream のメンテナーと作業を共有したい場合は、main から分岐してフィーチャー ブランチを作成し、作業が仕上がった段階でリモート リポジトリにプッシュします。
代わりに rebase を使用し、続いて merge することによって、upstream で評価対象のコミット一式 (理想には 1 つ) がクリーンな形になるようにすることができます。
git checkout -b feature-x
#some work and some commits happen
#some time passes
git fetch upstream
git rebase upstream/maingit fork で公開する
上記の手順が終わったら、簡単な push によって作業をリモート フォークに公開します。
git push origin feature-xgit push -f origin feature-x個人的には、できる限り履歴をクリーンな状態で保持したいので、オプション 3 を選びますが、チームによってワークフローが異なるものです。注意: この操作は自分のフォークで作業しているときのみ実行してください。共有リポジトリやブランチの履歴は決して書き換えてはなりません。
今日のヒント：プロンプトに 先行分 / 遅れ分 の数を表示する
fetch した後、同期している remote ブランチと比較して、先行/遅延しているコミット数が git status に表示されます。忠実なコマンド プロンプトでこの情報を見ることができたらいいと思いませんか? 私もそう思ったので、早速キーボードから bash を打ち込み、ツールを作りあげました。
設定が完了すると、プロンプトで次のように表示されます。
nick-macbook-air:~/dev/projects/stash[1|94]$これを .bashrc 等に追加してください。機能は 1 つだけです。
function ahead_behind {
curr_branch=$(git rev-parse --abbrev-ref HEAD);
curr_remote=$(git config branch.$curr_branch.remote);
curr_merge_branch=$(git config branch.$curr_branch.merge | cut -d / -f 3);
git rev-list --left-right --count $curr_branch...$curr_remote/$curr_merge_branch | tr -s '\t' '|';
}export PS1="\h:\w[\$(ahead_behind)]$"内部の仕組み
詳細と説明を知りたい人にために、このツールの仕組みを紹介します。
カレント HEAD、すなわちカレント ブランチのシンボル名を取得します。
curr_branch=$(git rev-parse --abbrev-ref HEAD);カレント ブランチがポイントしているリモートを取得します。
curr_remote=$(git config branch.$curr_branch.remote);このリモートのマージ先となるブランチを取得します (最後のフォワード スラッシュ [ / ] 以前のすべてを削除する UNIX のちょっとした技を使っています)。
curr_merge_branch=$(git config branch.$curr_branch.merge | cut -d / -f 3);これで先行しているコミットと遅れているコミットの数を収集するのに必要な材料が揃いました。
git rev-list --left-right --count $curr_branch...$curr_remote/$curr_merge_branch | tr -s '\t' '|';昔ながらの Unix の tr を使用して、TAB をセパレーターの | に変換しています。
git upstream の使用を開始する
これは git upstream の基本的なウォークスルーです。git upstream のセット アップ、新しいブランチの作成、変更の収集、git fork での公開の方法や、リモート ブランチから先行/遅延しているコミット数に関する便利なヒントです。
Bitbucket Data Center にはフォーク同期が含まれており、これにより、基本的に、開発者はフォークを最新の状態に保つというすべての負担から解放されます。また、Bitbucket Cloud には簡単な 1 ステップの同期機能があります。是非ご確認ください!
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
Bitbucket ブログ
DevOps ラーニング パス
