【学习笔记】git 之三：分支管理

第一：主分支master

        本地版本库中，每一次add，commit等操作，git会自动把这些操作串成一条时间线，这条时间线这也称之为分支，默认情况，为主分支master。

        每次提交commit，实质提交至当前工作的分支，HEAD相当于状态标记，指向当前工作的分支。

git branch

        查看所有分支，加*号的为当前的工作的分支。

        *mater       表示当前在master分支

第二：基于主分支创建分支dev

       1、 创建基于master的dev的分支，git背后的操作是，新增一个dev的指针，指向于master相同的提交，再把HEAD指向dev分支。

         此时工作区的文件并没有变化，不过以后add的文件，就提交到dev分支上。

git branch dev
git checkout dev

       以上语句分两步，第一步创建dev分支；第二步，切换到dev分支。

       等价于以下语句。

git checkout -b dev

    2、 在当前工作的dev分支上，添加文件夹moon,并提交

git add -A
git commit -m "tijiao moon file"

    3、查看所有分支文件

git show-branch
tig

以上两个语句，都可以查看所有分支的文件及提交记录

第三：推送本地分支至远程仓库

        前提，我们已经把本地库关联至远程仓库：git remote add origin git@---.git，

        并且，已经关联本地master分支和远程的master分支：git push -u origin master

git push origin dev

       以上语句，做了两件事情，一是在远程origin 创建了一个dev分支，二是把本地的当前工作的分支，关联到origin的dev分支上。

       如果在当前dev分支，直接git push，不加上origin dev远程分支，则报错。

第四：合并分支

 A、在dev分支上项目开发完成

1、切回master分支。  

git checkout master

       我们可以看到，当前在master分支下的工作区域，并没有出现之前在dev分支下，添加的文件夹moon。

       这也体现了，不同分支，对应不同平行宇宙空间，分支一旦建立，将各自独立。

     【基于某个父分支创建子分支，被创建的分支完全继承了，在创建这个时刻的，父分支的全部内容】

 2、因为dev分支已经开发完成，需要合并到master分支上。

git merge dev

git merge命令，用于合并指定分支，到当前分支。

这里是快速合并模式，即把master指向dev的提交。

3、推送至远程【git push命令只有在本地master，也就默认的分支下才工作】

git push

4、本地删除dev分支

git branch -d dev

    git branch  发现只有一个master分支

5、再次推送到远程【git push命令只有在本地master，也就默认的分支下才工作】

git push

   发现分支一旦被推送到远程，那么本地即便删除分支，对远程分支也没有影响

6、远程分支单独删除

 查看远程分支

git branch -a

删除远程分支

git push origin --delete dev

第五：合并分支问题---内容冲突。

1、基于master新建一个future_1的分支。

git checkout -b future_1

2、mong_1文件，由moon is usa修改为moon is not usa。然后在future_1分支，添加，提交。

git add moon/moon_1.py
git commit -m"moon is not usa"

3、future_1分支工作完成，切换master分支。

git checkout master

4、master分支下修改moon_1文件，moon is world。添加，提交。

git  add moon/moom_1.py
git commit -m"moon is world"

5、合并future_1分支

git merge future_1

因为我们在两个分支下，都修改了同一个内容，git无法帮忙快速合并。

6、查看moon_1.PY

<<<<<<< HEAD
moon is world
=======
moon is not usa 

>>>>>>> future_1

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存:

moon is world,not usa.

a、添加，提交

git add moon/moon_1.py
git commit -m"moon is world not usa."

b、合并

git merge future_1

成功合并

7、查看分支合并日志

git log --graph --pretty=oneline --abbrev-commit

8、恢复删除的分支

     选要指定被删除分支的散列值

git reflog

    执行 【git branch 你的分支名 SHA1值】

 git branch future_1 ac3b3d2

第六：普通模式合并

        优点：可以看出曾经的合并历史

        新增：采用--no--ff 需要做一个提交 -commit 

git merge --no--ff -m"no-fast merge" future_1

如果出现，Already up to date.则说明分支future_1,上的内容，相比较master内容没有变化，已经等同于合并后的效果【可能之前合并过，不过你自己忘了】

第七：bug修复分支

在基于master分支建立的future_1分支开发，完成一半，发下有一个bug要修改，切换主分支master，建立bug分支修复后，合并到master，并且删除分支。

1、保存future_1分支项目进度

git stash

    将future_1分支文件add，但是未commit 的文件保存下拉，切换到修改bug分支，不会出现future_1项目文件。

2、切换到master分支，并基于此创建，修复bug分支

git checkout master
git checkout -b fix_bug_1

3、在fix_bug_1分支修复bug，合并到master分支

git checkout master
git merge --no-ff -m"merge fix bug" fix_bug_1

4、切换到future_1分支继续工作，恢复此前stash文件，在上面继续工作。

     a、我们发现切换回来，并没有发现之前的文件，是被隐藏了，执行以下语句

git stash list

   输出：stash@{0}: WIP on future_1: f08f496 13:41

   b、需要执行以下语句，恢复现场，并删除隐藏

git  stash pop

5、继续修改，完成开发，切换到master分支，并合并

git add 修改
git commit -“”
git checkout master
git meger --no--f -m"" future_1

6、推送远程

git  push

因为之前都是普通模式合并，被合并的分支都被删除了，所有推送后，远程origin只有master这一个主分支。

第八：多人合作

1、从远程仓库clone：

     a、默认情况本地只会抓取origin的master分支下的所有文件。

     b、因为我们一般在dev分支上开发，所以必须要创建远程的dev分支到本地，执行以下语句

          git checkout -b  dev/origin dev

          拆开看，新创建本地dev分支，并对应到远程dev分支，且clone了当前时刻的远程dev分支的内容。

         【其实是和远程分支对应的创建本地分支，应该是并没有建立连接，所以当需要pull的时候，需要建立连               接git branch --set-upstream-to=origin/dev dev】

2、哪些分支，需要时刻推送

    a、主分支master

    b、dev开发分支

    其他分支，比如修复bug分支，新增功能分支，视情况而定

3、同事先于你推送了dev分支，你接着推送dev分支【语句是：git push origin dev】

     a、你执行了：git push origin dev  

     b、git提示推送失败，原因远程分支dev比你本地的dev更新。      

     c、 git提示需要把最新远程的内容origin/dev抓下来，执行 git pull 。     

            可能提示失败，原因没指定本地dev和远程origin/dev的链接，执行以下语句新建链接：

            git branch --set-upstream-to=origin/dev dev

     d、git pull成功以后，但是提示有冲突。

           git pull背后执行的操作，类似于分支合并，也就是把你的dev分支修改，和你同事的dev分支修改，合并             起来，但是如果，你们都修改了同样的内容，那么存在冲突，需要手动修改。

     e、因为存在冲突，git status 查看提示，然后修改冲突，并提交。

          解决冲突以后，执行git push origin dev。