2019/12/11 07-Git分支和工作流管理

一般来讲用的就是add,commit,push,pull,colone,对于checkout和reset，用的时候比较少，不要轻易的改名或者删除，一般项目开发的集成环境，一般叫IDE（比如pycharm），做项目就需要注意模块化了

做任何项目应该跟版本管理工具关联起来，一上来总有人做一个初始化构建，这个项目大概需要多少个模块，这些模块包先建立起来，然后告诉下面的人可以开发了，下面的人就去克隆
每个人有自己的账户生成一个密钥，把公钥添加进去即可
协议可以用gpl ，apache之类的，一般项目老大做这个是情感
现在就有两个项目

pycharm把当前项目关闭
就会出现这个界面
从自己的git服务器里拉
就是在这里得到的

成功不成功，需要试一下
上次的公钥是在windows家目录
现在就可以用公钥进行通讯，
项目所有管理目录，O:/pro,可以在里面创建CMDB目录，cmdb才是项目目录
这才是真正的项目目录

cmdb是一堆项目的跟目录，cmdb是开发的一个项目的目录
这里的log就跟git log一样
建立第一个文件，修改内容，vcs里面的commit和图标都可以提交

git status看一下
刚开始建立的时候，需要把ignore文件创建出来，这个文件可以加可以不加

*.是要被忽略的
现在就可以提交了
到log里看一下，一个用户在什么时间做了提交，head指向主分支
项目开发建立几个python文件

第一次提交

可以在目录里选择git push对应关系已经好了

查看一下config
当使用可视化工具去建立这个关系的时候，clone就已经把这个配置文件做好了
项目里已经有信息了

stash本身意思存储
git stash 暂时存储最后一次提交后的变化，放入栈中，这是另一种暂存机制

git stash pop 从栈中取出刚才变化，并合并到代码中，同时将栈中这个数据弹出

再写一个文件，加入git

提交一下

log这里就有两条了
提交之后完善代码

但是现在发现刚才的有问题，那么就需要先保存当前状态了，免得修改的丢失，可以先不提交，修改先暂存起来，暂存不是放在暂存区的，是放在stash功能里

随便起一个名字
现在就回到上一次 提交的状态了，commit2，等于stash记得上一次变化之后的修改变化
假设这个bug修复了
修复之后把这个文件提交上去
把bug修复后就提交，要进行说明

把刚才stash存储的
现在就有三次了

stash可以把上一次提交到现在的变化保存起来，可以先把提交的代码进行修改
不打勾表示保存的数据，还原了依然保留。打钩以后，pop就没了
代码就恢复了

记录的其实就是文件变化，整个git系统都是这样子的

可以继续开发

应用场景

直接push没有问题
有4次提交历史
bash是命令行，带有ssh这样的命令挺好用的，gui是图形界面
点开gui，可以看主分支上的文件

还可以看分支上的文件

可视化

提交历史，加加减减
作为一个项目管理者需要做分支了，分支的开发和分支的合并，一般都是项目管理者做的
到目前为止我们只看到一个master

多人开发的时候就不适合了，主分支肯定不适合多人开发，就需要引入多分支，多分支就要命名，名字就相当于唯一标识，标识不可重复，
下图，橙色代表第二分支，实际上是一个开发分支，两条线就需要各自做各自的事情
分支名在版本库中必须唯一
不能以-减号开头
可以使用/,但是不能以它结尾，被它分割的名称不能以.开头
不能使用两个连续的…
不能包含任何空白字符，git的特殊符号

到目前为止所有操作都是在主分支上
在某一个上面开始画分支

现在是4个节点，打算开一个分支，但是没commit，还没有节点

checkout branch ，开始往这条分支拐弯，如果不checkout，那么还是在master上
分支还没有commit节点，就还是4个

有了分支以后，完善app代码
现在在开发分支上写代码了
提交
现在head跟着dev跑，head是当前分支的最后一次提交

如果在dev上做了修改，就可以push
现在分支就有两个
历史都在
怎么合并

主分支上checkout

回到了下面的commit4提交了，checkout会把当前工作区替换掉
操作是先回到主分支上来
合并之后在主分支上产生一个新的提交
调用git的merage change，合并某一个分支数据到当前分支上来

这两个很重要
这块就发生改变了

选择no fast forward，就会在主分支上建立一个结点，主分支继续向前发展，合并到6上去
现在合并，只是在本地，还需要push到远程仓库

主分支上才有这个信息

fast forward的合并，最后变成一条线了，相当于dev消亡了

not fast forward，dev分支还在

fast forward会把分支修改拉回到master分支上去，最后看到分支图是一条直线

实际上 not fastforward 用的人比较多，因为可以看到什么时候开分支，什么时候合并了

no-ff的好处是，可以看清楚开发分支上的代码改动，大多数开发的时候，都会开辟一个分支是开发分支dev，在这个分支上增强功能，进行测试，审查，最终把代码合并到master
master只保留稳定的代码，是可以发布的代码
把代码放到master上
一般让运维或测试checkout出来，一个版本，进行部署，dev是开发分支，master是合并代码分支以及发布代码分支
中小规模的公司，两个分支足够了

git工作流，工作流在每家公司都不一样，看领导喜欢用什么
管理水平不够，也会代码混乱
master一般是合并完功能的一条分支，一般不直接做开发

测试不太适合到开发上直接拿代码
release这一块往往是测试可以参与的分支，测试完解决完，再发布到主分支master，主分支只放确认无误的代码
开发完成一个功能，可以称为一个里程碑发布出去，release
但是有的人懒，直接合并到主分支上上去，测试，测试完再发布，两条分支就这么做

matser主分支基本上放一些功能完成的代码、
hotfix，就是如果有问题，临时拉出来的热补丁修复，修复好了就合并进去，不仅是修复主分支，还有开发分支也需要，这样就适合临时修改主分支上的bug
release这个版本可以修复的发布到主分支，也发布到develop

一般公司用到三条就不错 了
很多公司就两条分支开发，测在master分支，直接在上面修复，然后直接提交

其实搞一个紧急修复的好一点，no-FF，对于测试发现的问题，紧急拉个分支来修复
**A同志做长线开发需要3个月，上面的是短期开发，做2周，都在完成各自的功能，，最简单也需要两分支开发
一般都是完成一个大模块，可能于10几个.PY文件（不会分配给A又分配给B，会合理分配一下，最后做代码审查）不会几个人改同一个文件
**

里程碑指的是，确实完成了一定的功能，通知测试组在哪个分支上拉代码进行测试，分支越多，管理水平要求越高
，或者AB公司不同的功能，就不合并了
大多数修改任务是add，commit，肯定是在某一条分支做开发的，合并和分支是非常复杂的管理功能（由项目管理管控）一般开发分支，主分支，发布分支差不多了

主分支上打标签，因为是给别人发不出去的

打标签 new tag
设置好标签了，可以查找
假设下面这个叫0.1
搜素可以跳转

打标签一般是在主分支上打标签，很少有人在开发分支上打标签
如果不清楚，没事就需要自己测测