git merge && git rebase silly you could not tell?

Lately busy, I have not updated the blog. Taking advantage of today's stage of completion of the project, an update.
In the development project, in order to carry out our project management, we need to use version control system, version control system is in the process of our system development, project each version of the changes will be saved to us. To ensure that future versions prior to a certain time we can retreat back. This blog mainly on a widely used GIT.

First, why the need to merge, rebase

GIT basic operation is relatively simple, not here to take the time to these. In multiplayer co-development process, often involvesmerge operationswithrebase operation, This time in the development process encountered this problem, we see a number of online tutorials, speaking of feeling foggy. We decided to tidy up the understanding to facilitate learning after learning the contents of this area.

Before explaining at these two operations, we need to understand why these two operations. In doing some small project, developers usually relatively small. If only one person who developed it, use git management is quite convenient. Only use each time you want to modify the git add to add to the staging area, git commit to submit to the local repository and then use git push to push to a remote repository. The entire process is not a branching timeline.

But as the project slowly complicated, personnel development projects become more, in order to facilitate project management. Developers should not be developed in the main branch, master should be stable branch version of our project. Therefore, we need to first remote codepullDown and then build their own locallydevBranch. at thisdevAfter the development, the development is complete,pushTo the remotedevOn request to the master branch merge.
The figure below shows the code remotely pull down, and then create a local dev branch
now the question is, because we realize development on the dev branch, and finally after we complete code development, is to be merged into the main branch of the local, and then push to the main branch or remote. == Note: The actual process is not so developed, remote master branch general developers do not have permission to push, otherwise everyone can submit to the master branch, you will have it. == This time you need to merge operations, and it can be a local dev branch into the master branch.
Another problem is that when we carry out the above operations, other developers have been very responsible for their own complete functionality, and push them to a remote repository merged into the master branch, then the following diagram this situation occurs. This time you will find that your local dev branch is developed based on version three, and in the process you develop, the need has been updated to version three versions of four, you want your dev branch based on the latest master branch, At this point you need to rebase operation.
#### two, merge examples

1. Switching dev branch

2. Development of new features under the dev branch, blue circled to add new content

3. Switch to the local master branch, this time found time.txt file and no content dev branch added
   
4. Fusion performed git merge

Now the integration is successful, you can see what has been added to the dev file in time.txt branch in master. If the remote master branch within this time no one submitted, we can submit directly to the local branch of the master to master the remote.

Three, rebase operation

About when to rebase the use of the above has been explained, the following demonstrates the use of rebase the case by a column. Suppose we now need two people to develop the project, the two were from a remote repository to push themselves locally and then push down on the branch development. The following diagram represents the time_Lc_dev and time_dev two different developers.

The two developers to develop based on the same master branch

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. But here we have the second option is to rebase operation, first of all we can in our local master branch using git pull command to ensure that our local master kept up to date == Note: this operation when Never use git merge will time_Lc_dev branch integration, it does not make sense. == This step does not create a conflict because time_dev is also based on the same master branch development. As shown below, this is our local master has the latest.
   At this point, our relationship time_Lc_dev local master branch and branch follows
   next is a rebase operation, will switch to the next time_Lc_dev latest master branch,It should be noted that: Yi time_Lc_dev must switch to the branch operation.
   Rebase now complete operation, as shown below:
   Then, after the completion of time_Lc_dev developers, commits switched to the main branch, the branch merging time_Lc_dev. You will find the master did not have a case branch. The blue line is generated before the fusion.