5

インテグレーターのワークフローを使用して git リポジトリを管理しています。言い換えれば、私は同僚からコミットをプルし、それらを祝福されたリポジトリにプッシュします。

ほとんどの場合、コミット履歴を線形に保ちたいので、変更を統合するときにa のrebase代わりに aを実行しても問題ありませんか? merge次に例を示します。

git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push

彼らが次にgit pull. git はこれを処理できますか、それともでのコミットの順序が異なるため、 でcoworkerリポジトリが失敗しますか?pullorigin

更新:私は元々、「マスター」から「同僚」ブランチをリベースする例を持っていました。私が意図したのは反対で、「同僚」コミットをマスターの上に置くことでした。だから私は例を更新しました。

4

5 に答える 5

3

あなたは間違いなくあなたが提案したことをしたくありません。masterブランチを同僚の にリベースしますmaster。あなたの同僚が何masterに基づいていたかによっては、しばしば中央を巻き戻すことになるかもしれませんmaster.

やりたいことは逆で、同僚のマスターをマスターにマージする前にリベースします。

git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push

ただし、これはまだお勧めしません。同僚は、変更のリベース方法を解決する必要があります。ほとんどの場合、それはおそらく些細なことであり、彼らはあなたのコミットを優先してコミットを破棄することができますが、それでもおそらく手動でチェックする必要があるものです.

個人的には、コミットを直接マージすることをお勧めします。それらがマスターの古すぎるバージョンに基づいており、マージが不必要に複雑であるか、不当に古いコミットに基づいていると思われる場合は、マスターをリベースして再フェッチするように依頼してください。そうすれば、少なくとも彼らはあなたがマージしているものを知っており、コード内の競合を解決します.

また、不必要に直線的な歴史を目指しないように注意します。並行して開発された開発者のブランチをマージすると、履歴をより正確に表現できます。マージする前に開発者のコ​​ミットをリベースすると、その開発者が修正して送信したコードの状態を正確に表すコミット レコードがなくなります。これはあまり問題にならないかもしれませんが、2 つのコミットが相互作用してバグが発生することがありますが、マージの競合は発生しません。リベースしないと、より正確な (そしてより公平な!) '非難' が得られます。

于 2009-08-13T22:05:50.330 に答える
1

git に関する膨大な量のドキュメントとチュートリアルの大部分は、リベースはプライベート ブランチでのみ使用するべきであり、他の誰かが見ることができるものではないことを明確にしています。あなたのモデルでは、説明のつかない障害が発生したり、他のレプリカで作業を繰り返さなければならないことを非常に恐れています。避ける！

于 2009-08-13T22:26:37.363 に答える
0

これは、些細なケースでは受け入れられるワークフローです。同僚が を実行するとき、git pull実際には のgit fetch後に が続きgit mergeます。Git はマージを行うのに非常に優れており、単純なケースを問題なく解決できます。

ただし、ステップで競合を解決するために何らかの作業を行う必要がある場合git rebase、同僚はプル時にその作業を再度行う必要がある場合があります。これは、コミットのシーケンスがリベース後のコミットのシーケンスとは大きく異なるために発生します。

非線形の履歴に慣れれば、おそらく Git はこのワークフローをより適切に管理できるようになるでしょう (Git はそれを処理するように設計されているため)。

于 2009-08-13T21:59:47.583 に答える
0

「マージ対リベース戦争で休戦？ 」の記事で述べたように、（私の強調）

おそらく、従来のリベースの最悪の問題は、コラボレーションが妨げられることです。
リベースの前後にリポジトリからプルする人は、2 つの履歴が互いに矛盾するため、競合を経験します。したがって、「公開されたリポジトリ内でリベースしないでください」という標準的な警告は、「後でリベースする可能性がある作業に協力しないでください」と言い換えることができます。

競合がないために「機能する」場合でも、リベース中に重要なマージを解決する必要がある場合、いくつかの問題が発生する可能性があります。

M0----M1----M2
\
 \
  \
   B1----B2

M0----M1----M2
            \
             \
              \
               B1'---B2'

(以前に公開された) ブランチの SHA-1 が書き換えられると、同僚は自分の環境でそのブランチをマージするのに苦労することになります。

于 2009-08-13T22:01:18.407 に答える
0

このワークフローでいくつかの簡単なテストを行いました。チャールズの投稿に同意しますが、他の情報を追加したかった.

長所

  • ワークフローは、ユーザーがパブリック リポジトリからプルすることを妨げません。
  • メインラインにプルされるコミットをより細かく制御できます。
  • メインライン ブランチの機能履歴をたどる方が簡単です。複数の変更をプルするためにマージ コミット (標準ワークフロー) を実行する必要がある場合、マージ コミットはすべての新しいコミットの変更を 1 つのコミットにグループ化します。これは、「1 つの機能を 1 つコミットする」というイディオムを破っています。

短所

  • 変更をプルしているレポでは、「元の」コミットが引き続き表示されます。これは、貢献者があなたが何をしているのかを知らない限り、混乱を招く可能性があります。これを回避する1つの方法は、プルしてリベースした後、貢献者に開発ブランチを破棄させることだと思います。
  • リベース後にリモート リポジトリが開発ブランチを破棄しない場合、マスター ブランチの履歴をリモート ブランチと一緒に追跡することが難しくなります。
  • リベース後、コミット時に元の作成者名が失われます。(ただし、これを手動で回避する方法があるかもしれません。) これにより、各変更を誰がコミットしたかを追跡することが難しくなります。
于 2009-08-25T23:29:25.903 に答える