レッスンGitは マージし、 Gitの比較リベース
git rebase このコマンドは、多くの場合、初心者は離れて滞在する必要があり、Gitの魔術と考えられてきました。適切に使用されている場合しかし、それはあなたのチームはたくさんの悩みを解消開発与えることができます。この記事では、比較するgit rebaseと同様のgit mergeコマンド、Gitのワークフローのすべてを見つけるために、リベースを使用しています。
アウトライン
あなたが知っておくべき最初の事はそれでgit rebase 、かつ 実際に行うのと同じです。これらは分岐が別のブランチにマージ変更できるように設計さが、その実装は多少異なっているされています。git merge
あなただけの新しい機能を開発するための特別なブランチを作成し、その後、チームの他のメンバーは、マスターブランチに新しいコミットを追加しました想像してみてください。これは、そのような状況のために協力することにGitを使用して、開発者は非常に一般的であるべきために提出履歴が、（フォーク）A分岐させます。
さて、あなたの仕事の機能と開発の新しい提出マスターは関連しています。マージやリベース：新しい提出や枝を組み込むためには、次の2つのオプションがあります。
オプションをマージ
機能ブランチにマスターブランチは、最も簡単な方法は、以下のコマンドを使用することです：
git checkout feature
git merge masterまた、あなたは行Yajianでそれらを置くことができます：
git merge master featureこれは、新しいマージ（関数は、（機能）枝がコミット作成するコミットマージ）一緒に歴史の二つの枝をリンクします。あなたは以下の分岐構造を得るでしょう：
幸いマージ、それは安全な操作です。既存の枝がリベース潜在的な欠点を回避するために変更されることはありません（後で言います）。
一方で、これはまた、各ブランチは無関係に提出するマージ機能を導入し、上流の変更をマージすることを意味します。マスターが非常に活発であるならば、それはあなたのブランチの多かれ少なかれ歴史を汚染します。高度なgit logオプションは、この問題を軽減することができますが、開発者のために、またはプロジェクトの歴史を理解することの難しさを増加します。
オプションをリベース
代替マージとして、あなたはmasterブランチにこの機能ブランチを好むことがあります。
git checkout feature
git rebase masterこれは、効果的にすべてのマスター上で提出された組み込みの新しいブランチを入れて、バックマスターブランチに全体の機能ブランチを移動します。しかし、プロジェクトの歴史を書き換えますリベース、それはマージコミットをもたらすが、元のブランチ上の各提出のための新しい投稿を作成しません。
最大の利点は、プロジェクトの歴史は非常にきれいになるコミットリベースということです。まず第一に、それはgitのない 不要な合併は、マージを提出導入として。第二に、上記のように、完全に線形を示す最終的なプロジェクトの歴史につながるリベース-あなたは、任意の分岐せずに開始されてから、ブラウザの終わりに突出することができます。これは、簡単に使用できるようになりgit log 、git bisect そしてプロジェクトの履歴を表示するgitk。
セキュリティやトレーサビリティ：しかし、この単純なコミットの歴史は二つの問題をもたらすでしょう。あなたが違反した場合は黄金律をリベースプロジェクトの歴史を書き換えるために、あなたの開発ワークフロー壊滅的な影響を与える可能性があります。また、リベース操作は、その背中を組み合わせ増加しない-あなたはブランチ機能ブランチ上流に一緒に来て何時間見ることができません。
インタラクティブリベース
対話型リベースはあなたが提出の新しいブランチに変更することができます。それはブランチ上の履歴を完全に制御を提供しますので、これは、自動リベースよりも強力です。一般的には、この機能は混乱の履歴をクリーンアップする前にマスターブランチに分岐するために使用されます。
gitのに-iオプションは、対話型リベースプロセスを開始、着信リベース：
git checkout feature
git rebase -i masterこれは、テキストエディタを開き、すべての提出が移動されます示しています：
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3 このリストには、分岐は次のようになります後リベースが実行されます定義します。ピック順序を変更するか、歴史のこのブランチを並べ替えるあなたのアイデアに応じて変更することができます。第二は、修正マイナーな問題を最初の提出を提出した場合たとえば、あなたは提出にそれらを一緒に入れてfixupコマンドを使用することができます。
pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
ファイルを保存して閉じ、Gitのリベースはあなたの指示に従って実行されますが、このようになります。プロジェクトの歴史：
マイナーな歴史的な特徴を無視することは、あなたがより読みやすい枝を提出できるようになります。これは 不可能。git merge
黄金のルールをリベース
[はいリベースかを理解すると、最も重要なことは、リベースを使用しないときです。git rebase 黄金律：一般的なブランチ上でそれを使用することはありません。
たとえば、あなたがブランチにmasterブランチをリベース場合は、あなたの機能にどのようなことが起こります。
これは、すべての機能ブランチのマスターすべての分岐を戻すリベースするために提出されます。問題は、他のすべての開発者がまだ元のマスターに取り組んでいる、それだけであなたのコードリポジトリで起こるということです。リベースは新しい提出を引き起こしたので、Gitはあなたのマスターのmasterブランチと他の人が分岐したと思います。
2本のマスターの枝を同期するための唯一の方法でコミットと山が同じ変更を含んで提出する追加のマージが得られ、それらを一緒にマージします。言うまでもなく、これは、人々は非常に混乱になります。
だから、あなたはGitのリベースを実行する前に、自分自身に尋ねるようにしてください、「他の誰かがこのブランチに取り組んであります？。」答えがイエスであれば、あなたの変更を送信するために（そのようにgit元に戻すなど）の音やり方を再発見するために、戻ってあなたの爪を入れました。そうしないと、あなたは歴史を書き換えすることができます。
強制プッシュ
あなたがリモートリポジトリにプッシュリベース後のブランチをマスターしたい場合は二つの枝が競合が含まれているため、Gitは、そうすることからあなたを停止します。しかし、あなたはプッシュを強制する-forceフラグを渡すことができます。ただ、次のように：
# 小心使用这个命令！
git push --force これは非常に奇妙に見えるのは、チームの他のメンバーのために、あなたの倉庫リベースの分岐後masterブランチに一致するように、マスタリモートを書き換えます。だから、あなたはときに再使用何をしているかを知っている場合にのみ、このコマンドは注意してください。
リモートリポジトリに構内をプッシュしたい場合（例えば、ロールバック）局所クリーンアップを実行し、プッシュを強制的にいくつかのシーンのいずれかを使用します。それは、言ってようなものだ「ああ、その機能ブランチの前に、実際には、私は現在のバージョンでそれを置き換える。プッシュする必要はありません。」また、あなたは誰もが機能ブランチで作業していないことに注意してください。
開発ワークフローに適用されます
あなたのチームのGitのワークフローに多かれ少なかれを適用することができリベース。このセクションでは、メリットは何リベース、機能ブランチの開発のさまざまな段階を見てみましょう。
ワークフローバランスのgitの最初のステップの負の効果をリベース特殊な機能ブランチの機能開発を作成することです。これは、分岐構造を使用すると、リベースの安全な使用を持っていることができます：
局所クリーンアップ
ローカルブランチをクリーンアップするために開発されているワークフローで最高の利用リベースのいずれかを使用します。時々、対話型リベースを実行し、あなたの機能ブランチは、各提出は具体的かつ有意義であることを確認することができます。あなたが原因を気にせずにコードを書くときに緩い提出 - あなたはこの問題を解決するためにリベースを使用することができます。
コールgit rebase （例えば、マスターなど）上流分岐または以前の投稿で、あなたの機能ブランチ：時間は、次の2つの考慮すべき行くためのオプションがあります。「インタラクティブリベース」1で我々は最初の例を見ました。最新の提出も有用である場合、後者では、わずか数時間を変更する必要がある場合。例えば、最新の3で次のコマンドでは、対話型リベースを提出しました。
git checkout feature
git rebase -i HEAD~3 通过指定HEAD~3作为新的基提交，你实际上没有移动分支——你只是将之后的3次提交重写了。注意它不会把上游分支的更改并入到feature分支中。 あなたは全体の機能ブランチを書き換えるために、このメソッドを使用したい場合は、gitの マージ・ベースのコマンドは、基本機能フォーク分岐が始まっ見つけることは非常に簡単です。このコマンドは、次のIDベースの提出を返し、あなたは次のgitのリベースにそれを渡すことができます：
git merge-base feature masterそれだけでローカルブランチに影響するため、対話型リベースgitのは、良い方法であなたのワークフローでの導入をリベース。他の開発者はあなたが行っている結果を見ることができ、それは非常にきれいで、分岐履歴を追跡することは容易です。
しかし、再び、これは構内で使用することができます。あなたは機能ブランチや他の開発者と協力している場合、このブランチが開いている、あなたは歴史を書き換えることはできません。
インタラクティブリベースと局所クリーンアップにより提出され、gitのを使用することは不可能である 代わりに、コマンドをマージします。
分岐機能に上流分岐の変化
概要では、我々はどのような特徴のgitのブランチを参照してください 上流分岐、マージまたはGitのリベースを組み込むこと。安全な選択をマージすることは、あなたの完全な履歴を保持あなたの機能ブランチはマスターブランチの背面に移動しますリベース、リニア歴史を作成することです。
gitのリベース使用及び局所クリーンアップに非常に類似している（かつ同時に使用することができる）が、間のマスターに上流の変更を組み込みます。
覚えておいて、リモートブランチというよりも、マスター完全に合法的にリベース。あなたとコラボレーションの同じ特徴点上の別の開発者は、この使用法を使用する場合は、その変更がプロジェクトに組み込まれました。
ジョンはリポジトリからフェッチした後、たとえば、あなたと服従のいくつかの枝を追加するための機能上の別の開発者--John--場合、リポジトリは次のようになります。
上流では、あなたは、このフォークを解決することができますので、マスターに同じ変更を組み込む：どちらかジョンの後ろにブランチをリベースするためにあなたの地元の支店と支店ジョンの、またはお近くの支店をマージします。
すべての物事が変更されていない前に、だけ移動されたローカルのブランチにコミットしているため、黄金のルールに違反していないここにリベースをリベース、注意してください。それは言ってようなものだ「私の変更はジョンの行くの背中に適用されます。」ほとんどの場合、リモートブランチを同期するには、この提出が合併を通じてより直感的です。
デフォルトでは、gitのプルコマンドでは、マージを実行しますが、リベースを介してリモートブランチを統合することを強制するために-rebaseを渡すことができます。
プル要求とレビュー
あなたのコードレビュープロセスの一環として、要求を引っ張った場合、あなたは、プルリクエストを作成した後にgitがリベース使用しないようにする必要があります。限り、あなたは、プルリクエストを開始すると、他の開発者は、共通のブランチに、このブランチを意味し、あなたのコードを見ることができます。Gitは歴史の書き換えになりますし、あなたの同僚は、それ以降の提出のこの困難なブランチを見つけます。
他の開発者からのすべての変更はgitのを使用する必要があります 代わりにGitのリベースのマージを組み込むこと。
そのため、コードのクリーンアップを提出する前に、対話型リベースプルリクエストを使用すると、通常は良いアイデアです。
機能を分岐することによって組み込ま
関数は、あなたのチームを渡された場合は、後の分岐を選択するマスターブランチをリベース、または使用gitができる メインのコードベースには、この機能をマージします。
この変更は非常に似ていますが、マスターブランチに提出書き換えないことができ、あなたは最終的にGitの使用する必要があります上流分岐機能に組み込まれます 。この機能を組み込むためにマージを。あなたがマージリベースを実行する前に、しかし、あなたはマージが直進であることを確認することができ、最終的に生成され、完全に線形の歴史をコミットしています。あなたもプルリクエストの後に提出追加できますこの方法です。
あなたがGitのリベースと完全に慣れていない場合は、一時的なブランチにリベース実行することができます。この場合は、あなたが誤って台無しあなたの機能ブランチの履歴があれば、あなたもオリジナルのブランチを表示して、もう一度試すことができます。
例えば：
git checkout feature
git checkout -b temporary-branch
git rebase -i master
# [清理目录]
git checkout master
git merge temporary-branch概要
あなたはこの中で、知識ポイントをリベース使用する前に知っておく必要があります。あなたがきれい、線形プロジェクトの履歴をしたい場合は、不要なマージコミットしない、あなたはgitの代わりにgitのリベースを使用する必要がある 他の枝に変更を組み込むためにマージします。
あなたがプロジェクトの完全な履歴を保存し、共通のブランチにコミット書き換えないようにする一方、あなたはGitの使用することができます マージを。両方のオプションは非常に使いやすいですが、少なくともあなたは今の選択肢のGitのリベースを持っています。
オリジナルソース