あなたが言うことができなかった愚かなリベースgitのgitのマージ&&？

最近忙しく、私がブログを更新していません。プロジェクトの完了の今日の段階では、更新を活かし。
開発プロジェクトでは、私たちのプロジェクト管理を行うために、我々はバージョン管理システムを使用する必要があり、バージョン管理システムは、当社のシステム開発の過程である、変化の各バージョンは、私たちに保存されますプロジェクト。私たちが戻って撤退することができ、特定の時間に先立って、将来のバージョンを確認してください。主に広く使用されてGITにこのブログ。

まず、マージするなぜ必要性、リベース

GIT基本的な操作は、これらの時間を取るためにここにない、比較的簡単です。多人数の共同開発プロセスでは、多くの場合、必要としますマージ操作とリベース操作、開発プロセスのこの時間は、この問題が発生し、我々は感情の霧といえば、オンラインチュートリアルの数を参照してください。我々は、この領域の内容を学習した後、学習を容易にするための理解を整理することを決めました。

これら二つの操作で説明する前に、私たちは、なぜこれらの2つの操作を理解する必要があります。いくつかの小さなプロジェクトをやって、開発者は通常、比較的小さいです。それを開発した一人だけが、使用している場合はgitの管理は非常に便利です。あなたがステージングエリアに追加するgitのアドオンを変更するたびにのみを使用し、ローカルリポジトリに提出してからリモートリポジトリにプッシュするgitのプッシュを使用することをコミットgitの。全体のプロセスは、分岐のタイムラインではありません。

プロジェクトが徐々に複雑としてではなく、人材開発プロジェクトは、プロジェクト管理を容易にするために、より多くなります。開発者は、メインブランチで開発すべきではない、マスターは、私たちのプロジェクトの安定した分岐バージョンでなければなりません。したがって、我々は最初にリモートでコードに必要引くダウンして、ローカルに自分自身を構築DEV支店。この中DEV現像後、開発が完了すると、押すリモートへDEVmasterブランチのマージへの要求で。
コードがリモートでプルダウンして、地元のdevのブランチを作成ショー下図
我々はdevの枝に発展を実現し、最終的に我々の完全なコード開発の後、地元の主枝、その後、プッシュにマージされるので、今の質問ですメインブランチまたはリモートに。==注：実際のプロセスは、そうでない場合は、誰もがマスターブランチに提出することができ、あなたはそれを持っていますが、一般的な開発者がプッシュする権限がありませんので、開発し、リモートのmasterブランチではありません。==今度は、マージ操作をする必要があり、それがmasterブランチに地元のdevの枝することができます。
もう一つの問題は、我々は上記の操作を行う際に、他の開発者が独自の完全な機能のために非常に責任があった、とリモートリポジトリにプッシュ、masterブランチにこのような状況が発生し、次の図を合併していることです。この時間は、あなたの地元のdevのブランチがバージョン3に基づいて開発されていることがわかりますし、あなたが開発プロセスでは、必要性は三つのバージョン4のバージョンに更新されている、あなたがしたい、最新のmasterブランチをもとに、あなたのdevの枝、この時点で、操作をリベースする必要があります。
#### 2、マージ例

1. スイッチングのdevの枝

2. devの枝の下で新機能の開発は、青が新しいコンテンツを追加して丸で囲みました

3. ローカルのmasterブランチに切り替えが、今回はtime.txtファイルと添加していないコンテンツのdevの枝を見つけました
   
4. Fusionはgitのマージを行いました

今、統合が成功すると、あなたはマスターでtime.txtブランチでのdevのファイルに追加されているかを見ることができます。この時間内にリモート・マスター・ブランチは誰が提出した場合、我々は、リモートを習得するために、マスターのローカルブランチに直接提出することはできません。

三、リベース操作

上記の使用について説明したがリベースする際について、次のように列でリベース例使用方法を示します。私たちは今、プロジェクトを開発するために二人を必要とし、2はローカルに自分自身をプッシュするリモートリポジトリからのものであったし、その後分岐開発を押し下げ。次の図はtime_Lc_devとtime_devつの異なる開発者を表します。

同じマスターブランチに基づいて開発するには、2つの開発者

1. 现在在time_Lc_dev开发人员开发还未完成的情况下，time_dev完成了自己的功能（添加了add.txt文件），并合并到本地的master，push到远程的仓库。
   

2. 此时对于开发人员time_Lc_dev来说，他所开发的分支并不是基于最新的分支，并没有远程master仓库的add.txt文件。现在我们有两种选择，一个就是继续在我们的分支上继续开发，最后在合并到本地的master分支上，然后推送到远程master分支上，不出意外的话，应该会出现问题。另外一个选择就是进行rebase操作，对我们当前开发的分支（time_Lc_dev）进行变基，随后在进行开发，开发完成后，合并到本地master，然后push到远程仓库就可以。
   下图为现在分支的状况，可以看出time_Lc_dev分支比master分支晚一个版本。
   

3. 此时，如果我们不去理会目前的这种情况，继续在我们的分支上开发，开发完成之后，添加到本地master，然后向远程master分支提交的时候就会发生如下问题。这就是我们之前说的没有变基的后果，其实这个也简单，按照提示，先git pull下来，然后在进行git push提交就可以了。
   至此，就完成了由于开发人员提交到远程分支时间不同而引起的冲突。但是这样会带来一个问题，就是会是我们的master时间线不在是一条单一的时间线，而是会出现分支。如下图所示，这样特别不方便项目后期的查看和管理。

4. しかし、ここで我々は最初のgit pullコマンドを使用して私たちの地元のマスターブランチ内のすべての我々はできるの地元のマスターは日付==注意の状態に維持することを確実にするために、第二の選択肢は、操作をリベースすることがあります。この場合の動作決してをtime_Lc_dev支店の統合は、それは意味がありませんでしょうgitのマージを使用します。time_devも同じmasterブランチの開発に基づいているため==このステップは、競合を作成しません。以下に示すように、これは私たちの地元のマスターは、最新のを持っています。
   この時点で、私たちの関係time_Lc_devローカルマスターブランチとブランチは次の
   次のリベース操作で、次のtime_Lc_dev最新のmasterブランチに切り替わります李time_Lc_devが分岐動作に切り替える必要があります：ことに留意すべきです。
   下に示したように、今、完全な操作をリベース：
   次に、time_Lc_devの開発が完了した後、コミットはブランチがtime_Lc_devをマージ、メインブランチに切り替えます。あなたはマスターがケースの枝を持っていなかったでしょう。青い線は融合前に生成されます。