github でプロジェクトをフォークし、変更をアップストリームに送信する予定の場合、いくつかのワークフローが考えられます。これは、私が通常従う傾向があるワークフローの 1 つです (フォークした元のリポジトリを remote として呼び出し、リポジトリを として呼び出しますsource) origin。
- が使用するメイン ブランチをフォークし
sourceます。masterorigin/my-dev
origin/mydev私のすべての変更と主な開発が行われる場所です。
- 私は定期的にリベース
remote/masterしますorigin/master(この手順は冗長ですが、1 つのリモートにすべてを簡単にまとめられる場合があります)。
- アップストリームから変更を取得したいときはいつでも
source/master、またはリベースorigin/masterをマージします。origin/my-dev
- アップストリームにパッチまたはバグ修正を提出したい場合は、プルリクエストに使用できる新しい機能ブランチを開始します。私はそれを呼びます
origin/my-feature-1。このブランチを最新origin/master(またはsource/master)から作成します
- に加えたこの機能の変更をチェリーピックし
origin/my-devますorigin/my-feature-1。この手順の後にテストを実行します。
- からプル リクエストを送信します。
origin/my-feature-1
- プルリクエストが承認されると、変更がマージされます
source/master(およびマージされorigin/masterます)。
origin/master(またはsource/master)から へのマージを実行 しorigin/my-devます。
- ブランチの存続期間に関する限り、私は通常、存続期間の短いトピックまたはフィーチャー ブランチをアップストリームにマージした後、それらを取り除く傾向があります (ブランチは、特定のコミットを参照する git の軽量ポインターにすぎません)。
このワークフローを何度も繰り返します。
重要な考え方は、あなたのプルリクエストが上流のメンテナに重大な衝突を引き起こしてはならないということです。
アップストリームから貢献D2したい場合の例を示しました。とは、とのリベース バージョンです。のコミットは のアップストリーム コミットであり、 のダウンストリーム コミットです。サフィックスが付いているものはマージです。D3origin/my-devD2'D3'D2D3UsourceDoriginM
視覚的には、次のようになります。
source/master origin/my-dev
U1
U2 Initial-fork
U3-----------\
| \
| \------------D1
| D2
U4 Sync up from upstream |
U5-----------\ D3
| \ |
U6 \------------DM4 origin/feature-1
| |
| | Starting point of feature-1
U7------------------------------------------------------------D2' (Rebased version of D2)
| | D3' (Rebased version of D3)
| D5 /
U8 D6 Pull-request /
| | getting merged upstream /
UM9--------------------------------------------------------/
| |
| Resync |
|-------------\ my-dev |
U9 \ |
U10 \-----------DM7
| |
| |