git操作工作流

本文旨在为一些git新手讲解git工作流上的操作，使大家更清晰的认识到git相关的操作，不再为因为不会git操作，连代码都不敢合。

git的作用是什么

git是一个版本管理工具，同样常见的还有svn。就概念上来说，git是分布式的，svn是集中式的，两者有很大的思想上的差别。

快速了解git相关操作

在介绍操作命令时，首先讲解一个概念：本地分支与远程分支。

远程分支：

用来做生产(origin-master)、测试环境(origin-develop)的分支，很多情况下由开发组长进行控制，做自动化构建（如 Jenkins）拉取的远程代码。一般来说，每次的远程代码推送，都代表实际的一个开发/测试环境版本。

本地分支：

与远程分支无关的本地电脑缓存区代码。你可以从任何一个远程分支拉取代码作为自己的本地分支，如 origin-master上拉取到本地的代码 master。这样可以做版本代码的bug修复。本地分支的代码，对于代码管理者（开发组长-管理远程分支代码）来说，

只要你没有将本地代码推送到远程，他就看不到你的代码的。

常用的几个命令概念解析：

1. commit 提交本地代码（本地代码做了更改之后，如果此时需要进行分支切换或者推拉远程代码，都需要首先提交本地代码，这样才不会报错。）
2. checkout 切换/检出分支 （这个是修复线上版本特定问题的神技，可以从特定某个分支版本节点上检出代码，或者切换本地不同分支代码）
3. pull 拉取代码（每次在推送代码之前 需要先拉取一下相对应的远程分支，这样可以将其他人提交的代码先拉到本地，如果远程有与自己本地将要提交的代码有同一地方的更改，就会有冲突，这时候需要进行解决冲突）
4. 解决冲突时，需要对比自己的代码与远端拉取下来的代码，非冲突部分，别人的与自己的都要保留，如果是冲突的地方，需要与相应的开发人员进行沟通，进行冲突解决。解决完成后，需要再进行代码提交，或者是标记冲突解决
5. push 推送代码（需要选择对应的远程分支进行推送，一般在不进行版本更新时，需要将代码推送到自创的远端分支上，再由开发组长，将代码合并到相应的远端分支）

git工作流 图示：

Git分布式协作：

图解：所有人都会从一个远程分支（由项目负责人决定）拉取（checkout）代码，如master。每个人拉取完代码后，会在本地进行业务/bug开发。每个人开发的模块或许都不一样。只要在没有向master进行push（一般master的push功能会被开发组长限制，

正常可能会push到develop等开发测试分支。）远程master的代码就一直不会改变。

简而言之所谓的分布式协作就是，git远程分支是一个中心，大家都从远程拉取代码，在各自的本地进行开发，开发完毕之后，再统一推到远程master，这样就完成了多发协作开发。

图中的commit是一个提交代码的操作，这个提交是提交到本地缓存，这样本地也就有了比如master这个本地版本，当然，你也就可以任意创建本地分支，只要你自己能明白自己在哪个分支，在做什么。

冲突产生及解决

这里引出一个问题，如果说大家开发的有相同的模块，如小黄与小吴同时在修改图片上传的页面。此时，如果小黄先推送了代码，小吴后推送了代码。那么master上修改图片的页面是不是就存在两个人代码，这样master的代码就可能会被报错（所谓的冲突）

那么如何解决这种问题呢？

 所以，大家必须养成一个好习惯。本地代码在进行commit提交后，需要先对远端分支进行一个拉取远端分支的操作 push。这样，如果多个人修改了同一个文件有冲突，可以先在自己本地发现冲突并且联系相对应的开发人员进行沟通解决冲突。

再讲代码提交进行推送。这样可以避免远端分支受到污染。

工作流图

 解析：

一般来说 稍微正规点的环境管理会有 测试环境，准生产环境，开发环境。其中准生产环境用来作为与master（生产环境）保持同步，进而保护生产环境代码。对于测试来说，准生产环境通过之后，才能允许上线（master）

情景一：

如果小黄需要将自己本地开发环境的代码推送到测试环境让测试人员进行测试，就需要进行 commit pull push操作将本地代码的提交到开发/测试环境。然后通过自动化部署，如Jenkins进行构建。

情景二：

当前生产环境（master版本号为5的）有bug，需要小黄进行修复。那么此时小黄就需要将自己本地的代码进行commit保存，然后从master（生产环境代码）切出一个版本作为本地代码，

然后推到一个新的远程分支比如（fixed-修复图片失效）。

这里其实有个问题，不同公司处理的方式也不同。

我们可以看到 代码修复了，也推送到了远程分支，但是此时我们的测试环境有现在正在开发的版本6代码。如何将现在生产环境（版本5）修复的代码推送到测试环境呢，如果直接推到 远程测试环境/开发环境，那么会因为

含有当前6版本的开发代码导致环境里的代码不纯洁，测试测的时候回含有版本6的代码。一般常见的处理方式有以下几种：

1：从远程测试/开发环境，切出一个分支，推送到新的远程（如 orgin-测试环境-备份），再将远程的测试环境删掉，此时将fixed-修复图片分支的代码推送到测试环境，让测试进行测试。通过之后再同样的方式上到准生产（如果准生产也有版本6的代码，如果没有

版本6的代码是不需要进行删除准生产环境代码的）。上线完成后，再将将现有的测试与准生产环境进行删除从备份中取出。

2：如果公司是自动化构建，如Jenkins，此时可以配置自动化构建拉取的远端代码为 fixed-修复图片，这样就保证测试环境 直接拉取版本5的修复版本了。准生产环境一样的道理，需要新建远程分支，进行Jenkins配置。

 注意

如果顺利上线了，我们将代码切回小黄的版本6开发代码。此时我们需要注意的是，master代码有了一个修复版本，版本号就变成了如5.5，那么我们需要做一下代码同步

 

 图解：

首先我们需要将master代码 直接拉到本地，如果有冲突，解决冲突，随后一级一级往开发、测试、环境推送，最后上准生产，环境。这样所有的版本代码（黄色的圆点）代码就是一样的了。

最后

讲解无太多经验，如果有不懂的，欢迎留言我进行补充。旨在为不懂git一些操作的人解决问题，不然会大大对开发进度还有质量造成影响！

推荐一款桌面化的git版本控制工具：sourtree，如下图，可以查看到当前本地的分支，还有远端分支。以及每次合并时的节点 还有哪些人在协作。非常通俗易懂，适合新人上手