一文理清项目中如何正确使用git

Posted 2021-10-27 白玉梁

一般的，我们在进行新项目开发时，首先都会创建一个git仓库，并自动生成了一个默认的主分支origin/master，这里我估计有超过一大半的开发人员，就直接在master分支上开始干活了，特别是就该项目就一个开发人员时！

这种方式好不好？肯定是不好的，但有些开发人员可能并不这么认为，觉得这样简单方便，没什么问题！但其实只是你的业务简单，让你没有遇到令你棘手的问题而已！试想，如果你v1.0上线后，v2.0开发了一半，而v1.0出现了严重bug需要紧急修复时，如果你只有master分支该怎么办？ master现在是被污染的，无法回到v1.0时的状态去修复bug，你说你可以用reset，那你需要先把当前开发进度备份，然后reset，修复后再把修复的内容与你备份的内容手动合并，或者你说你v1.0上线后你有备份，直接在备份上修复然后再手动合并到master！好吧，如果你觉得你完全胜任这份额外的工作，那倒也不是问题，但这已经完全失去了使用git的意义！

正确的使用方式：

master作为受保护的主分支，一定要保证代码是最后一次打包上线的状态，它是稳定的，不被污染的，开发人员不能直接在master上进行开发，保证任何时间打开master，都是最后一个线上稳定版本的代码！

一般的，我们需要在master基础上创建一个新的开发分支— —dev，然后开发人员在dev分支上开发，开发完毕后，合并到master上，然后在master上打包上线！

这种方式，我想一样会有一大部分开发人员是这么做的，特别是2-3个小开发团队，这样做其实也无可厚非，大家都在一个开发分支上工作，写完即提交，简单方便！但往往，我们会发现一些问题，例如，A在开发a功能，B在开发b功能，A在提交自己的代码时，B先一步进行了提交，但恰恰是B的提交影响了A的提交，比如因为B的一些失误没有提交全，或者代码修改错误，或者直接跟A的提交产生了冲突，导致A在提交后，无法正常运行，那么A就要花大量工作去解决这些问题，但，实际上，A开发的功能可能与B没有任何关系，但B总是影响A，或者反过来相互影响，这就直接导致了整体开发进度推迟！

试想如果团队有4个5个以上的开发人员呢？所以这里，我们就需要从dev分支中，再次根据开发人员创建自己的分支，A创建一个A专用的分支，B创建一个B专用的分支…，开发完毕后，各自再merge到dev分支，在dev分支上解决问题后，再合并到master分支，互不影响，加快开发进度！

但实际上，这种方式也会有弊端，因为开发团队人员越多，那么开发过程中的项目改动，必然会穿插交错，这就会直接导致再往dev上合并时，会经常产生冲突，那么这就需要考验项目管理者的能力了，要对项目整体框架的设计以及开发人员的任务划分做到尽可能的合理，尽量避免相互影响！

所以，该怎么选，还是要结合自身项目以及开发团队情况而定！

继续，在某个版本开发完毕打包上线后，一般的，我们需要在master上为这个版本打上一个tag，这个tag是当前稳定版本整个项目的copy，跟分支很像，但却不同！我们可以这么理解，tag是静态的，就像对一个项目的备份，打完tag即封存，适时取用；而分支则是动态的，我们需要在分支上进行开发！

实际开发中，我们还经常会遇到这样的问题：

正在开发v2.0的过程中，发现了线上v1.0重大bug，需要立即修复，但v2.0功能只开发了一半，无法达到上线状态，此时，就需要在master上创建一个bug分支，因为master一直是最后一个稳定版本的代码，所以创建bug分支后，直接在bug分支上修复，完毕后合并到master，再在master上打包上线，并删除bug分支即可！

但问题是，我这边还在开发着v2.0呢，dev上肯定也有这个bug，如果是不同人员负责bug修复，那到无所谓，合并到master后，你可以继续合并到dev，或者使用git cherry-pick xxx命令复制bug修复的提交，到dev！当然如果dev也修改了同样的文件，你就需要解决冲突了！但如果你正在开发v2.0，同时又要解决bug，此时建议不要直接在当前项目上切换到bug分支进行修改，可以换一个地方单独clone bug分支，否则你需要使用git stash储藏当前v2.0的开发现场，待bug修复合并后，再切换回dev执行git stash pop恢复现场，就可以继续在dev上干活了！

第二个问题，因为开发需求会经常变更，假如某一天boss说需要开发一个新功能，但这个功能属于预研阶段，可能根据业务情况上线，也可能不上线，但同时又不能影响正常的版本迭代，那么此时就要用到feature分支，在master上新建一个feature来专门开发新功能，开发完毕后，等待boss或产品经理确认，上就合并到dev，最终合并到master，不上可以留存或直接删除即可！实际上它的操作与bug分支没有什么区别，但是意义不同！

正确理解git分支的不同意义，会在实际开发中达到事半功倍的效果！你，get到了吗？