リベースは何ですか？
- Gitはあなたが実際にそれが「再設定したベースライン、」であることを理解することができリベースあなたの現在のブランチは、開始点を再設定します。この時間は、あなたが比較する必要が枝に現在のブランチの違いを知ることができます。
原理は簡単です：あなたの現在のブランチは、最新のブランチを追跡しているので、現在のベースラインの枝は、トラックの最新の枝の端面にタイムラインをバックに移動し始めている枝の枝に基づいて、現在のベースラインを設定する必要性をリベース。ここでの操作は、トランザクションファイルに基づいているので、あなたは、ファイルに影響を与えます一貫性の中で、障害の恐れである必要はありません。プロセスの途中で、あなたはいつでもリベースで取引をキャンセルすることができます。
だから、gitのリベースとgitのは、エンド違いは何にマージ？
、最終面の共通ブランチに、いわゆるリベースをあなたの現在のブランチをコミットしますリベース。再び、あなたは枝のような一般的なブランチから引き出す場合。例えば：あなたは、あなたがいくつかのコミット提出し、masterブランチから特徴を引き出した場合、それは彼が開発しただけのものだったこの時間は、マスターに枝を引っ張って、あなたがコミット時よりもさらにいくつかを習得するには、この時間を合併あなたはリベースこの時点で開発する場合、それは、あなたがいくつかの現在のコミット取るの背面にその人をコミットします。
国民はブランチをマージし、マージしますあなたの現在の提出新しいコミットを形成するために一緒にコミット
イラスト：
以下に示すように、バグ修正二股分岐がマスタから分岐されています。
リベースを使用した後：
今度は、ソリューション簡単に言えば合併の過程でそれを見てみましょう。
まず、masterブランチにバグ修正のブランチをリベース、歴史バグフィクスブランチはmasterブランチに後で追加されます。図に示すように、ライン履歴、かなりきちんとしました。
そして、競合する可能性があり、XとYが提出した移動、時にその提出紛争の一部を変更する必要があります。
- rebase 之后，master 的 HEAD 位置不变。因此，要合并 master 分支和 bugfix 分支，即是将 master 的HEAD移动到 bugfix 的 HEAD 这里。
使用 merge 之后：
- merge 会把两个分支合并在一起，形成一个新的 commit 提交
注意:
尽量不要在公共分支使用 rebase
本地和远端对应同一条分支,优先使用 rebase ,而不是 merge
因为往后放的这些 commit 都是新的,这样其他从这个公共分支拉出去的人，都需要再 rebase,相当于你 rebase 东西进来，就都是新的 commit 了
1-2-3 是现在的分支状态
这个时候从原来的 master , checkout 出来一个 prod 分支
然后 master 提交了4.5，prod 提交了6.7
这个时候 master 分支状态就是1-2-3-4-5，prod 状态变成1-2-3-6-7
如果在 prod 上用 rebase master , prod 分支状态就成了1-2-3-4-5-6-7
如果是 merge
1-2-3-6-7-8
........ |4-5|
会出来一个8，这个8的提交就是把4-5合进来的提交
** merge 和 rebase 实际上只是用的场景不一样**
更通俗的解释一波.
- 比如 rebase,你自己开发分支一直在做,然后某一天，你想把主线的修改合到你的分支上,做一次集成,这种情况就用 rebase 比较好.把你的提交都放在主线修改的头上
- マージ、彼の頭の上にマージが8の合計を身に着けていた場合は、ブランチを提出あなたにロールバックする場合は、非常に面倒である、重要な問題があり、リベース、私は枝から引っ張っていた3の外にありますその後、私は私の開発ブランチから引き出された場所からわからないが、オーバーリベース
- あなたは、人々が見たい場合は、メインブランチに他の枝を変更リベース、リベース使用している場合は同様に、メインブランチの歴史が、彼は完全な歴史の授業ではなく見て、この歴史はあなた改ざんされているものではありません