したがって、リモート(追跡)ブランチであるブランチを使用していて、最新のものを取得したい場合、それを実行する必要があるかどうかはまだわかりませgit pull
んgit rebase
。git rebase
他のユーザーと一緒にブランチで作業しているときに、彼らが引っ張ったりリベースしたりすると、彼らを台無しにする可能性があることを読んだと思いました。本当?私たち全員が使用する必要がありgit pull
ますか?
5 に答える
Git pull は 2 つのコマンドの組み合わせです
- git fetch (ローカルリポジトリをリモートの最新のものと同期します)
- git merge (もしあれば、遠いブランチからの変更をローカルの追跡ブランチにマージします)
git rebase は git merge とほぼ同等です。リモートでは何も取得しません。実際、適切なマージも行わず、2 番目のブランチからの新しいコミットの後に、現在立っているブランチのコミットを再生します。
その目的は、主に履歴をきれいにすることです。gitk の過去の履歴がひどくスパゲッティのようになる前に、多くの人が多くのマージを行う必要はありません。
ここの最初の 2 つの図で、最適な図による説明を見ることができます。しかし、ここで例を挙げて説明しましょう。
master と mybranch の 2 つのブランチがあります。mybranch に立っているとき、私は走ることができます
git rebase master
そして、mybranch での最新のコミットの前に master に新しいものを挿入します。マスターの mybranch からのものをマージまたはリベースすると、新しいコミットが最新のコミットの直後に直線的に追加されるため、これは完璧です。
あなたが言及している問題は、「間違った」方向にリベースすると発生します。最新のマスター (新しい変更を含む) を取得したばかりで、マスターから次のようにリベースする場合 (ブランチを同期する前):
git rebase mybranch
今私がしたことは、新しい変更をマスターの過去のどこかに挿入したことです。コミットのメインラインが変更されました。また、git がコミット ID を処理する方法により、新しい変更に対して再生されたばかりのすべてのコミット (マスターから) には新しい ID があります。
うーん、言葉だけで説明するのは少し難しいです...これが少し意味をなすことを願っています:-)
とにかく、私自身のワークフローはこれです:
- 「git pull」リモートからの新しい変更
- マイブランチに切り替える
- 「git rebase master」を使用して、マスターの新しい変更をコミット履歴に反映します
- マスターに戻す
- 「git merge mybranch」。master のすべてが mybranch にもある場合にのみ早送りします (したがって、パブリック ブランチでのコミットの並べ替えの問題を回避します)。
- 「ギットプッシュ」
最後に一言。違いが些細な場合 (たとえば、異なるファイルまたは少なくとも異なる行で作業している人々) は、リベースを使用することを強くお勧めします。先ほど説明しようとした落とし穴がありますが、よりクリーンな歴史になります。
重大な競合が発生する可能性がある場合 (たとえば、同僚が一連のファイルの名前を変更した場合など)、すぐにマージすることを強くお勧めします。この場合、競合を解決してから解決をコミットするよう求められます。プラス面としては、競合が発生した場合にマージを解決する方がはるかに簡単です。欠点は、多くの人が常にマージを行うと、履歴をたどるのが難しくなる可能性があることです:-)
幸運を!
Gitrebase
は歴史の書き換えです。「公開」されているブランチ (つまり、他のユーザーと共有しているブランチ) でこれを行うべきではありません。誰かがあなたのブランチを複製し、あなたがそのブランチをリベースした場合、彼らはあなたのブランチから変更をプル/マージできなくなります.彼らは古いものを捨てて再プルしなければなりません.
git を使用したソフトウェアのパッケージ化に関するこの記事は、非常に読む価値があります。これはソフトウェア配布の管理に関するものですが、非常に技術的であり、ブランチをどのように使用/管理/共有できるかについて話しています。彼らは、いつリベースするか、いつプルするか、そしてそれぞれのさまざまな結果について話します。
要するに、どちらにもそれぞれの役割がありますが、その違いをよく理解する必要があります。
git pull
リモートブランチにないコミットがある場合、マージを行います。git rebase
リモートブランチの先端に関連する必要がある既存のコミットを書き換えます。どちらも競合を引き起こす可能性があるという点では似ていますが、git rebase
if you can を使用すると、よりスムーズなコラボレーションが可能になると思います。リベース操作中に、リモート ブランチの最新リビジョンに新しく適用されたように見えるようにコミットを調整できます。マージはおそらく、より多くの履歴を持つブランチでのより長い開発サイクルに適しています。
git の他のほとんどのものと同様に、さまざまなスタイルの作業に対応するために、多くの重複する機能があります。
リモート ブランチに影響を与えず、ローカル コピーを変更せずにソースをプルしたい場合は、git pull を使用することをお勧めします。
変更を加えた作業ブランチがある場合は、git rebase を使用してそのブランチのベースを最新のリモート マスターに変更します。ブランチの変更はすべて保持されますが、ブランチはマスターからブランチされます。以前に分岐した場所ではなく、場所。