Git分支管理

1.Git添加远程仓库

首先，登陆Gitee，然后，在右上角找到“新建仓库”按钮，创建一个新的仓库，
注意不要选择初始化仓库和模板，要创建一个空的仓库 ，填写仓库名称，其他保持默认设置，点击“创建仓库”按钮，就成功地创建了一个新
的Git仓库。

创建成功后会显示仓库地址和简单入门命令

现在，我们根据GitHub的提示，在本地的 learngit 仓库下运行命令：

git remote add origin [仓库地址]

添加后，远程库的名字就是 origin ，这是Git默认的叫法，也可以改成别的，但是 origin 这个名
字一看就知道是远程库。
下一步，就可以把本地库的所有内容推送到远程库上：

git push -u origin master

由于远程库是空的，我们第一次推送 master 分支时，加上了 -u 参数，Git不但会把本地的 master
分支内容推送的远程新的 master 分支，还会把本地的 master 分支和远程的 master 分支关联起来，在
以后的推送或者拉取时就可以简化命令。

推送成功后，可以立刻在gitee页面中看到远程库的内容已经和本地一模一样：

从现在起，只要本地作了提交，就可以通过命令：

git push origin master

把本地 master 分支的最新修改推送至Gitee，现在，你就拥有了真正的分布式版本库！

2.分支管理

分支就是git世界的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里
努力学习SVN。
如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并
了，结果，你既学会了Git又学会了SVN！

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了
50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码
全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支
上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支
上，这样，既安全，又不影响别人工作。
git相对于其他版本控制工具，分支功能非常快

2.1 创建与合并分支

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。
截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即 master 分支。 HEAD 严格来说不是指
向提交，而是指向 master ， master 才是指向提交的，所以， HEAD 指向的就是当前分支。
一开始的时候， master 分支是一条线，Git用 master 指向最新的提交，再用 HEAD 指向 master ，
就能确定当前分支，以及当前分支的提交点：

每次提交， master 分支都会向前移动一步，这样，随着你不断提交， master 分支的线也越来越
长。
当我们创建新的分支，例如 dev 时，Git新建了一个指针叫 dev ，指向 master 相同的提交，再把
HEAD 指向 dev ，就表示当前分支在 dev 上：

你看，Git创建一个分支很快，因为除了增加一个 dev 指针，改改 HEAD 的指向，工作区的文件都没
有任何变化！
不过，从现在开始，对工作区的修改和提交就是针对 dev 分支了，比如新提交一次后， dev 指针往
前移动一步，而 master 指针不变：

假如我们在 dev 上的工作完成了，就可以把 dev 合并到 master 上。Git怎么合并呢？最简单的方
法，就是直接把 master 指向 dev 的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除 dev 分支。删除 dev 分支就是把 dev 指针给删掉，删掉后，我们就剩
下了一条 master 分支

命令

• git checkout
  • git checkout – file：把版本课的文件重置到工作区（撤销工作区的修改）
  • git checkout master：切换到master分支
  • git checkout -b dev：创建dev分支，并且切换到dev分支
• git branch
  • git branch：列表分支分支，有*当前的分支
  • git branch dev：创建dev分支，如果切换需要git checkout dev
  • git branch -d dev：删除分支
• git merge：合并分支

2.2 实战

1.首先，我们创建 dev 分支，然后切换到 dev 分支：

git checkout -b dev

## 或使用branch
git branch dev
git checkout dev

2.用 git branch 命令查看当前分支：

git branch
#git branch 命令会列出所有分支，当前分支前面会标一个 * 号。

3.然后，我们就可以在 dev 分支上正常提交，比如对 readme.txt 做个修改，加上一行，然后提交：

$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+)

4.dev 分支的工作完成，我们就可以切换回 master 分支

$ git checkout master
Switched to branch 'master'

5.现在，我们把 dev 分支的工作成果合并到 master 分支上：

$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)

6.合并完成后，就可以放心地删除 dev 分支了：

$ git branch -d dev
Deleted branch dev (was b17d20e).

7.删除后，查看 branch ，就只剩下 master 分支了：

$ git branch
* master

2.3 版本冲突

两个分支同时修改提交了同一个文件，进行分支合并时，会出现版本冲突问题。
准备新的 feature1 分支，继续我们的新分支开发：

$ git checkout -b feature1
Switched to a new branch 'feature1'
git branch feature1 #创建分支
git checkout feature1 #切换分支
git branch #查看分支

修改文件并提交

$ git add readme.txt
$ git commit -m "AND simple"
[feature1 14096d0] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)

切换到 master 分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)

在 master 分支上把 readme.txt 文件修改并提交

$ git add readme.txt
$ git commit -m "& simple"
[master 5dc6824] & simple
1 file changed, 1 insertion(+), 1 deletion(-)

现在， master 分支和 feature1 分支各自都分别有新的提交，这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲
突，我们试试看：

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

果然冲突了！Git告诉我们， readme.txt 文件存在冲突，必须手动解决冲突后再提交。 git
status 也可以告诉我们冲突的文件：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")

我们可以直接查看readme.txt的内容：

我们修改如下后保存，在提交

$ git add readme.txt
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed

冲突解决

2.4 分支管理策略

在实际开发中，我们应该按照几个基本原则进行分支管理：
master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在 dev 分支上，也就是说， dev 分支是不稳定的，到某个时候，比如1.0版
本发布时，再把 dev 分支合并到 master 上，在 master 分支发布1.0版本；
你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合
并就可以了。
所以，团队合作的分支看起来就像这样：

模拟两个开发人员（bob,mickey）进行开发
bob开发人员

#创建本地dev分支
git checkout -b dev
#提交dev给服务器
git push origin dev
#创建bob的本地分支
git checkout -b bob
#创建env.txt
touch env.txt
#提交
git add .
git commit -m "add env bob"
#回到dev，合并bob分支
git checkout dev
git merge bob
#上传dev到远程
git push origin dev

mickey开发人员

cd f:\mickey
git clone git@gitee.com:lxsong77/learngit.git
#注意，只下载master分支，其他分支不会被clone
git checkout -b dev
git branch --set-upstream-to=origin/dev dev
#等价于
git checkout -b dev origin/dev
#拉取dev分支
git pull origin dev
#创建mickey分支
git checkout -b mickey
#修改env.txt增加内容"mickey env"
vim env.txt
#提交
git add .
git commit -m "update env by mickey"
#合并到dev
git checkout dev
git merge mickey
#上传
git push origin dev

合并到master分支

#拉取最新代码
git pull origin master
git pull origin dev
git checkout master
git merge dev
#上传
git push origin master

这样两个开发人员就完成了合作开发。