2

まあ言ってみれば

  • githubでプロジェクトをフォークしました
  • 複数の人（5人未満）がこのフォークに取り組んでいます
  • 目標は、変更を加えてプルリクエストを行うことです

フォークに数回コミットした後、フォークをソースプロジェクトの最新のHEADに更新します。複数の人がこのフォークに取り組んでいるため、標準的な方法は、ソースプロジェクトをプルダウンしてから、マージコミットを実行して、ソースプロジェクトから最新のHEADを取り込むことです。

これは履歴を非線形にし、多くの「役に立たない」マージコミットが発生するため、これは好きではありません。

私たちの代替案は次のとおりです。

  1. git pull --rebaseを使用して、ローカルに最新のフォークされたHEADを作成します
  2. フォークをリベースして、コミットがソースHEADの後に続くように、新しい最新のHEADソースを取り込みます。
  3. git push --force
  4. 他のすべての人はgitpull--rebaseで最新のものを入手します（これはすべての人のデフォルトにすることができます）

歴史は直線的であり、フォークのコミッターのためにいくつかの調整を行っただけです。

このアプローチの問題は何ですか？

4

4 に答える 4

4

あなたはここから始めます（U上流です、Yあなたのものです）：

UB--U1--U2
 \
   Y1--Y2

次に、リベース (およびpush -f)を実行します。

UB--U1--U2--Y1'--Y2'

これで、他のチーム メンバーがpull --rebase次のことを行います。

UB--U1--U2--Y1'--Y2'--Y1''--Y2''

robinst が指摘したように、競合を解決する必要がある場合、git はリポジトリに と のバージョンが既に存在することに気付かず、Y1再度Y2リベースします (おそらくいくつかの醜い競合も発生します)。

マージを行うことをお勧めします（ で線形履歴を確認できます git log --no-merges）。リベースの方法を本当に試してみたい場合は、次のことができます。

あなたが実行します：

git fetch --all
git branch rebase_base master
git push origin rebase_base
git rebase upstream/master
git push -f origin master

その後、他の全員が実行されます。

git fetch origin
git rebase --onto origin/master origin/rebase_base master

なぜこれが機能するのか見てみましょgit help rebaseう;)。基本的に、すでにリベースを行ったコミットまで git up を指示しているrebase_baseので ( )、必要のないものはリベースしません。

于 2013-03-13T01:28:36.387 に答える
1

手順2でリベースを実行するときに競合を解決する必要がある場合、手順4は他の人にとって問題なく機能しない可能性があります。

その理由は、GitがパッチIDを介してコミットを比較することでコミットがすでに適用されているかどうかを検出するためです（git patch-idを参照）。競合を解決するために変更を行うため、パッチIDが変更される場合があります。

そのため、他の人が手作業を必要とする場合があります。たとえば、ローカルの変更をリセットしたり、チェリーピッキングしたりします。

于 2013-03-12T17:34:58.957 に答える
1

必要ありませんgit push -f。リベースとマージ (それぞれ viagit pull --rebaseとgit pull) は 2 つの選択肢であり、どちらかに従うことで、ブランチをアップストリームで最新の状態に保つことができます。

実行しgit pull --rebase、競合があれば解決し、「役に立たない」マージ コミットのない履歴を楽しみ、実行するだけですgit push

于 2013-03-12T17:22:41.803 に答える
0

簡単に言えば、自分のブランチへのgitpush-fには何の悪もありません。悪い部分は、他の開発者と調整する必要があるときに発生します。あなたがフォースプッシュをしている正確な瞬間に全員がコミュニケーションをとっていない限り、それは複雑になる可能性があります。複雑さを回避するために、すべての開発者は、強制的なプッシュに対応するために行っている作業を停止する必要があります。それはワークフローを混乱させ、不必要な時間と労力を費やすことになります。

分散バージョン管理システムの良いところは、編集に対応するために開発者に作業をやめるように依頼する必要がないことです。古き良き時代には、開発者（a）がファイルをチェックアウトすると、VCSシステムはファイルの悲観的なロックを取得し、他の開発者（b）はスクランブリングを行って最初の開発者（a）を見つける必要がありました。ファイルをチェックアウトし、開発者（b）がファイルを編集できるように、開発者（a）にファイルをチェックインするように依頼します。しかし、私は話題から外れています。

トピックに戻ると、トピックブランチワークフローを使用することでメリットが得られると思います。フォークにブランチを設定してmaster、フォークした元の作業を追跡します。マスターには、元のプロジェクトのすべての作業が含まれています。

チームが新しい機能を開発するとき、どこかで変更をマージする必要があります。developmentチームが変更をプッシュ/プルできるように、名前などの名前の新しいリモートブランチを作成することは珍しくありません。この新しいリモートブランチは、事実上、trunkチームのブランチです。

master元のプロジェクトから分岐したプロジェクトのブランチに変更をマージする責任を誰かが負う必要がありますがdevelopment、トランクへの強制的なプッシュに対応するように全員に依頼するよりもはるかに簡単です。また、フォークされたプロジェクトのマスターブランチと開発ブランチのポリシーを設定する必要があります。このワークフローにより、開発者は独自のワークフローを中断することなく、フォークされたリポジトリをプル/マージできます。

于 2013-03-13T14:58:16.837 に答える