当前位置：首页 > news >正文

如何使用GIT管理项目代码

news 来源：原创 2025/5/20 9:10:57

介绍

Git是目前世界上最流行甚至最好的开源分布式版本控制系统，不论是很小的项目还是很大的项目，它都能有效并且高效的处理项目版本管理，初衷是为了帮助管理linux内核代码而开发的一个开放源码的版本控制软件。

GIT常用分支名称

分支	分支名称	分支是否永不销毁
feature-【功能名】	本地功能需求分支	否，功能需求开发完毕上线之后进行删除
develop	测试不稳定版本分支	是
release	预发稳定版本分支，始终和生产版本一致	是
hotfix-【漏洞名】	生产问题修复分支	否，问题修复完毕进行删除
master	生产稳定版本分支	是

工作流

Git管理项目，并没有特定的框架或者软件去帮我们完成：开发 - 测试 - 生产，这一过程的项目版本控制，有的只是给每个项目提供Git代码管理方案，施行该方案还是需要依靠项目的管理人员，这里的方案称之为Git工作流。总结下来，目前大概有四种工作流。

1.集中式工作流

这种工作流和之前流行的SVN类型，它只有一个master分支，开发者会先把远程的仓库克隆到本地，之后的修改和提交都在本地操作，直到在某个合适的时间点将本地的代码合入到远程master。这种工作流比较适合小团队，因为小团队可能不会太多的协作和合流的动作。

2.功能开发工作流

这种工作流关注功能开发，为保证它是稳定并且干净的不会直接往master提交代码，而是从master拉取feature分支进行功能开发，团队成员根据分工拉取不同的功能分支来进行不同的功能开发，这样就可以完全隔离开每个人的工作。当功能开发完成后，会向master分支发起Pull Request，只有审核通过（也叫Code Review）的代码才真正允许合入master。

3.Gitflow工作流

这总工作流比较复杂，适合大型项目多人维护情况，下面将会整队这种工作流做详细说明，大概流程就是：从develop分支拉取一个feature分支当做新需求的开发分支，开发完毕合到develop进行测试，测试完毕要发布更高级环境时develop合并到release，最后发布生产release合并到master结束。当生产突然又bug时，从master分支拉一个hotfix分支解决bug，最后将hotfix合并到master，其他分支release、develop等需要实时拉取解决过bug的master分支。

4.Forking工作流

Forking工作流常用于开源项目，它有一个公开的中央仓库，其他贡献者可以克隆这个仓库作为自己的私有仓库，开源项目维护者可以直接往中央仓库push代码，而代码贡献者只能将代码push到自己的私有仓库，只有项目维护者接受代码贡献者往中央仓库发起的Pull Request才会真正合入。

GitFlow工作流深入探讨

上面四种工作流，1和2都比较简单不用多说（目前统一账户就是这两种形式结合使用），4是适合开源项目，所以3是重点讨论对象。特别强调，使用何种方式管理在git上托管的项目，需要根据项目自身的情况、人员情况（人数和个人技术素养）制定最适合项目组的方案，以上的工作流只是一个建议或者说是一个框架。

在目前微服务盛行的情况下，加之项目的业务及功能日趋复杂，出现了一个项目很多个子项目、一个项目有众多的开发人员情况，

这种情况下，出现最多也是最容易出错的问题有：多个需求多人同时开发代码分支问题、多个同时开发的需求分不同时间上线代码分支及合并问题、在日常无需求或者正在开发需求的时候生产出现bug后修复bug的代码分支及合并问题。下面针对这些情况使用GitFlow工作流结合上面“GIT常用分支名称”表给出方案。

模拟日常开发场景

多人开发

这里的同时指的是两个及以上的需求代码都未发布生产环境。

场景：需求1由开发人员A负责开发，需求2由开发人员B负责开发，且都在本周一开始进行开发，周四需求1发布生产，周五需求2发布生产；

开始开发：A本地从master分支拉一个名为feature-需求1分支进行需求1开发，B本地从master分支拉一个名为feature-需求2分支进行需求2开发，因为develop是测试分支，很有可能包含未上线或需要修复bug的代码，所以需要从稳定版本的分支拉取代码进行新需求开发；

发布测试：无论A和B是同时发布测试，还是有先后顺序的发测试，都涉及到一个A与B的本地feature分支代码谁先合到develop分支的问题，因为后合并到develop的feature可能会面临代码冲突的情况，一般这种情况需要后合分支的开发人员找发生冲突的代码负责人员商议冲突解决办法，develop分支每合一次feature都会发布一次测试环境；

发布预发：周二时A需要将需求1的代码发布到预发环境，根据GitFlow工作流，发布更高级环境，需要将develop分支代码合并到release分支，但是此时develop分支拥有需求1和需求2的代码，需求2的代码此时还有bug未解决不能将代码合到release污染到release分支代码，所以合develop到release的方案从一开始就不在项目管理的方案内，A此时直接将自己本地的feature-需求1分支提交合并到release分支，因为feature-需求1分支本身就是从release拉出来的（release=master），可以说是完美契合没有任何冲突，feature分支每合一次release分支都会发布一次预发环境；周三时B需要将需求2代码发布到预发，和A一样的操作即可，而且B合代码时，也不需要考虑代码冲突问题（因为在develop分支测试环境已经解决过他们两之间的冲突了）；

发布生产：周四A的需求1发布生产，A的本地feature-需求1分支申请合并master发布生产，周五B的需求2发布生产，B的本地feature-需求2分支申请合并master发布生产; 每次master分支新增代码，必须要做的操作就是向下合并一次代码给release和develop分支（虽然它们不会因此有什么代码改动，但是为了保险），然后正在开发的其他feature分支也需要立刻从master同步代码到自己feature分支以保证本地开发版本的代码与生产一致；如果需要需求1和需求2一同发布生产，那可以在release分支两个需求代码都测试好了，通过将release分支合并到master再发生产，如果有三个需求，有两个需要一同发布生产，可以在feature代码提交到master后先不立即发布，等下一个需要一起发的需求代码feature合过来再发布；

出现bug：周三生产突然出问题，bug需要紧急修复且优先级高于一切需求（这是肯定的），此时开发人员C从master分支拉取一个名为hotfix-bug1的修复分支，进行修复，修复完毕hotfix-bug1合到develop发布测试、合到release发预发、合到master发生产，发布测试的时候如果遇到和测试的代码冲突，一切以hotfix分支的代码为准进行冲突解决，当生产发布解决过问题后，master会多了修复之后的代码，此时其他的所有未发生产的feature本地需求开发分支都需要将master新代码合到自己分支来。

总结

以上多人开发模拟的场景，是理想流程下，要求前提是（总结就是需要项目是微服务或靠近微服务）：1.项目是大型多子模块项目；2.项目不同的子模块分不同的人或组负责开发维护；3.当一个需求涉及不同的项目模块的时候需要多模块人明确分工协同开发（如一个app内新活动需求，需要用户系统和活动系统协同，用户系统向活动系统提供用户的基础操作能力，活动系统完成新活动开发）；4.一个feature分支只干一件事儿，不能跨模块或需求；

在多人开发一段中，A和B先后向develop合并代码，如果A和B的代码改动涉及到了同一文件，那么git就要求需要合上来的feature分支先拉取develop的代码，然后才能合，但是这样就导致了有一方的feature会包含其他feature的代码。

最终还是需要根据实际项目制定最适合的方案，上述方案是根据自身微服务经验及同行朋友的经验得来，可能会有不足和欠考虑的地方，而且上述方案流程复杂繁琐（可以去掉release分支这一环节），对管理人员和开发人员都有一定的要求（是否能长久坚持，是否有自我管理意识，不取巧，不图省事儿）。

Git子模块

子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。它能让你将另一个仓库克隆到自己的项目中，同时还保持提交的独立。

常见使用场景

1.项目A需要用到组件B，但是又不想每次在组件B有新版本后向组件B的开发人员要新包来使用，可以使用git子模块将组件B的git代码引入作为自己项目作为子项目，当组件B有更新时自己随时打包使用；反过来，我的组件B同时被好多项目使用，我不想每次更新后发新包给各个项目负责人，可以使用子模块功能让各个使用项目自行更新组件B的代码去使用。

2.一个大型多模块的项目，除了核心模块不便暴露，其他模块都可以交给外包或者其他部门联合开发，此时使用git子模块功能，将所有模块变更为git子模块，将对应的git子模块交由其他人员开发，彼此互不打扰且不知晓其他人的代码内容。

3.多人合作的大型多模块git项目，需要将每个模块作为可以独立提交的git项目，但是又要保证所有模块又要受到该git项目的统一管理，使用git子模块功能完美解决。