git学习笔记（10分支例子）

一&＃xff0c;常规情况下操作

1-1&＃xff0c;正常情况下&＃xff0c;已经有稳定的代码版本了。

1-2&＃xff0c;现在想要更新项目&＃xff0c;就新建一个分支&＃xff1a;

可以看到&＃xff0c;head指向master&＃xff0c;而新分支也指向当前的版本&＃xff0c;只是此时head没有指向它而已。

1-3&＃xff0c;现在我们想在新分支上修改代码&＃xff0c;而不影响原有master版本的代码&＃xff0c;则可以把head切换到bran1分支上来&＃xff0c;这样工作区就变成新分支bran1下的了。

1-4&＃xff0c;现在可以进行代码修改等操作&＃xff0c;然后提交新版本。

可以看到&＃xff0c;master已经被保留下来了&＃xff0c;而我们此时是在bran1分支下进行操作。

1-5&＃xff0c;如果想切换回到master主分支上来&＃xff0c;那就切换呗&＃xff0c;不过值得注意的是&＃xff0c;一旦切换&＃xff0c;工作区中的内容就会变成master对应版本的文件内容了。


此时的版本信息是上图这样的。

实际上&＃xff0c;切换分支会变更三个地方&＃xff0c;第一个是head的指向&＃xff0c;第二个是暂存区&＃xff0c;第三个地方是工作区。
所以&＃xff0c;每次切换分支前&＃xff0c;当前分支一定要是干净的&＃xff01;&＃xff08;全部提交了&＃xff09;

1-6.为什么说切换分支时当前分支一定要是干净的呢&＃xff1f;
仔细考虑一下&＃xff0c;如果在当前工作区新建了一个文件&＃xff0c;没有纳入git管理&＃xff0c;那么一旦切换分支&＃xff0c;因为这个文件没有纳入管理&＃xff0c;则git管不了它&＃xff0c;他就会出现在切换的分支那边&＃xff0c;容易污染之前稳定的版本文件。
需要把新建的文件纳入git管理&＃xff08;add&＃xff09;之后才不会出现这种情况。
这种情况发生在文件第一次出现&＃xff08;未纳入git管理&＃xff09;时才会发生&＃xff0c;如果已经纳入git管理了&＃xff0c;又进行了变更而没有暂存和提交&＃xff0c;则无法切换分支&＃xff0c;会报错。
1-7&＃xff0c;要避免这个问题也简单&＃xff0c;只要你切换分支前检查下当前分支是干净的就不会出错。

二&＃xff0c;一个小案例

此时的项目是这样的&＃xff1a;

2-1&＃xff0c;主分支的代码是稳定的&＃xff0c;不能动&＃xff0c;所以创建一个新分支&＃xff1a;
之前我们创建一个新分支&＃xff0c;然后让head指针指向它&＃xff0c;现在有一个新的写法&＃xff0c;可以一步到位&＃xff1a;
git checkout -b "新分支名字"
此时假如我们正在解决日常的事物&＃xff0c;新建了一个分支来进行代码的编写&＃xff1a;

2-2&＃xff0c;开始日常事务中解决#53的bug &＃xff0c;假设现在已经做了一半的工作。

就在这时候&＃xff0c;有个紧急bug需要你去处理&＃xff0c;但是你已经在53分支上做了一半工作了&＃xff0c;这工作能删除嘛&＃xff1f;显然不能&＃xff0c;那就先停下来。
先把它提交一下&＃xff1a;

再来看分支 情况&＃xff1a;

2-3&＃xff0c;现在就可以切换到主分支解决紧急问题了&＃xff1a;

2-4&＃xff0c;同样的&＃xff0c;为了保证不影响主分支的代码。处理这个紧急bug又需要新建分支。

2-5&＃xff0c;现在才开始着手解决这个紧急的bug。


如上图红圈&＃xff0c;出现了两个分支&＃xff0c;目前head指针指向正在修改bug的分支上。
假如此时已经解决了这个bug。
2-6&＃xff0c;修复bug后合并到主分支。

1. 切换回到主分支。
2. 然后让主分支合并hotbug分支。

现在再来查看&＃xff1a;

这种合并方式是快进合并&＃xff0c;会产生一个问题&＃xff1a;iss53分支现在过期了。。也就是说iss53分支上还没有修复bug。里面的主分支代码还是之前有bug的版本。
2-6&＃xff0c;代码的bug解决完毕了&＃xff0c;hotbug分支没有存在的意义了&＃xff0c;那就把它删除掉吧。

你以为这样就结束了&＃xff1f;&＃xff1f;&＃xff1f;
不&＃xff0c;现在的主分支是修复了bug没错&＃xff0c;但是此时的主分支仅仅在你自己的电脑上存在&＃xff0c;中央管理的代码库里还是旧的&＃xff0c;这时就需要你更新一下啦。
需要将本地修改的代码推到服务器上面去。&＃xff08;现在github还没学&＃xff0c;先这样&＃xff09;
现在就相当于这个bug已经解决掉了&＃xff0c;现在需要再切换回iss53继续今天的事务。
2-7&＃xff0c;切换回当天事务&＃xff1a;
目前这个iss53才完成了一半&＃xff0c;但是为了切换出去紧急修复bug&＃xff0c;提交了一次。


此时iss53已经被修改完成。现在要合并的话&＃xff0c;又需要切换到主分支&＃xff0c;然后合并&＃xff1a;
2-7&＃xff0c;依旧是快进合并

你会发现这个版本已经修复了bug。
值得注意的是&＃xff0c;因为我们修复bug和修复iss53各自独立进行&＃xff0c;所以合并只是简单的进行取并集而已。但若是两种更改都对同一个文件进行变更&＃xff0c;此时合并会出现什么情况&＃xff1f;
因为是相同文件&＃xff0c;git又不知道你合并后要删除哪些&＃xff0c;保留哪些&＃xff0c;此时合并后&＃xff0c;就会发生冲突&＃xff0c;不过他会告诉你冲突的文件&＃xff0c;只要点进去&＃xff0c;修复一下冲突&＃xff0c;再提交一下就可以了。
此时的合并叫做&＃xff1a;典型合并


打开冲突哪个文件&＃xff0c;哪个代码留下来&＃xff0c;哪些删除。沟通完之后再add,commit就可以了。
2-8&＃xff0c;这样一来&＃xff0c;紧急bug修复好了&＃xff0c;当天的事务iss53也好了&＃xff1a;

现在分支少&＃xff0c;还挺清晰&＃xff0c;真正工作中&＃xff0c;分支很多&＃xff0c;超级难看。
现在为止&＃xff0c;都是你自己在和自己解决代码版本啦&＃xff0c;冲突啦这些问题&＃xff0c;你自己心里有谱&＃xff0c;还好解决。实际工作中的话&＃xff0c;就是各种同事各种版本&＃xff0c;要是发生冲突&＃xff0c;就得和同事积极沟通了。说不过就打他&＃xff0c;打到对方改为止&＃xff08;滑稽脸&＃xff09;
所以说&＃xff0c;进公司后&＃xff0c;第一步就是把同事打一顿&＃xff0c;啊&＃xff0c;不是&＃xff0c;是先创建属于自己的分支。然后要新增代码啦&＃xff0c;增加功能啦啥的&＃xff0c;就在自己的分支上搞&＃xff0c;就把问题变成自己和自己玩了&＃xff0c;避免天天被同事打。
等你自己负责的功能完成了&＃xff0c;再整合到主分支上即可。