基于git的代码版本管理规范及流程 - Ray(Mr.huang)

时间：2024-01-31 07:14:14

基于git的代码版本管理规范及流程

代码库分类

根据代码库分布的位置及作用，分为以下几类：

  • 主库：位于服务端，所有开发的代码最终都要合到主库。
  • 个人代码库（服务端）：从主库fork出来，位于服务端。每个人自已开发的代码，由本地的git库push到每个人自己的个人代码库（服务端），再由个人代码库（服务端）合入主加。
  • 个人工作库：位于每个开发人员的开发机器，从个人代码库（服务端）clone到本地。每个开发人员开发的代码，先commit到个人工作库，再由个人工作库push到个人代码库（服务端）。

人员角色分类

这里说的角色，都是人员在主库上的角色。基于简化的原则，人员分为三类：

  • Owner：拥有主库的所有权限。
  • Committer：具有将开发人员的合并需求（MR）合入主库的权限。基于安全考虑，我们设置为只能通过MR的方式将代码合入主库，而不能直接push到主库。
  • Developer：只能从自己的个人代码库（服务端）提交合并代码的请求（MR），是否能够合入，由Committer进行审核。

基本流程

在主库已经存在的情况下，日常操作流程如下：

  1. 开发人员从主库fork出自己的个人代码库。
  2. 开发人员将自己的个人代码库clone到本地，即个人工作库。
  3. 开发人员在开发了新代码后（包括新增和修改），先将代码commit到自己的个人工作库，再由个人工作库push到个人代码库。
  4. 开发人员提交从个人工作库到主库的MR，Committer审核后，决定是否将MR合入主库。
  5. 每个开发人员从主库pull最新代码到个人工作库。

分支管理

  • 主库缺省的master分支，是用来向生产环境发布的，所有合入的代码，原则上都必须是稳定的。
  • 主库除了master分支外，至少还要有一个活动分支，命名建议为：br_工程名_active，平时日常的开发都基于活动分支开发。即从个人工作库提交MR到主库时，指向的是主库的活动分支。活动分支测试稳定后，将主库的活动分支通过MR的形式，合并到主库的master分支，同时打上tag。
  • 如果软件运行过程中发现必须立即修改的bug，则从主库的master分支中，拉出一个bugfix分支。为修复这个bug的所有开发，都基于bugfix分支。待bugfix分支开发完成，并测试稳定后，将bugfix分支以MR的方合入主库的master分支。然后删除bugfix分支，视情况决定是否打tag。

常见问题

　使用git在本地创建一个项目的过程：

$ makdir  G:\python    　　　　     ##创建一个项目文件夹
$ cd G:\python          　　　　    ##打开文件夹
$ git init                      　 ##初始化本地git仓库
$ git commit -m \'first commit\'     ##提交更新并添加备注“first commit”

　　以上为本地仓库创建提交流程

　　登录码云，创建一个项目python，添加README文件，复制链接

$ git remote add origin https://git.oschina.net/xxxxxx/python.git     ##连接远程github项目  
$ git push -u origin master        ##将本地项目更新到github项目上去

　　容易出现的问题及常用命令：

git status                 ##查看git状态
git pull origin master     ##pull远程仓库
git remote                 ##查看远程仓库及其分支
git rm origin              ##删除本地仓库

　　问题1：执行git remote add xxxx报错fatal: remote origin already exists.

　　解决办法：git remote rm origin删除远程仓库的origin，然后再add添加远程仓库

　　问题2：执行git push origin master报错fatal: I don\'t handle protocol \'git@https\'

　　解决办法：那是因为你用了git@github...的add方式添加了远程仓库，请通过问题1删除远程仓库再重新添加

　　问题3：执行git push origin master报错error: failed to push some refs to...

　　解决办法：大部分是由于github中的README.md文件不在本地代码目录中导致的， 先通过git pull --rebase origin master进行合并，再通过git push -u origin master上传

　　问题4：执行git pull origin master报错fatal: refusing to merge unrelated histories

　　解决办法：这是一个常见问题，要把两个不同的项目合并，需要添加一个强制命令：git pull origin master --allow-unrelated-histories

　　问题5：如何添加一个.gitignore，或者如何添加一个目录（文件）到ignore中

　　解决办法：一、还未添加git的项目：在项目目录下新建一个.gitignore文件（Windows无法新建命名为.gitignore，可以命名为.gitignore.，但是我更推荐使用sublime等工具来创建命名即可），在.gitignore中添加你需要过滤的文件即可。添加完成后git init即可；二、已经进行了git操作的项目，需要通过命令把相应的过滤文件缓存进行清空，清空后将代码push，同步端直接pull即可：

git rm --cached -r [目录名]
git commit -m \'clean ignore files\'

　　问题6：" refusing to update checked out branch: refs/heads/master, By default, updating the current branch in a non-bare repository is denied, because it will make the index and work tree inconsistent……"

　　解决办法：这个错误是我在搭建裸仓库时碰到的，主要原因是git初始默认receive.denyCurrentBrach是拒绝接收push的，我们要向中心仓库push就需要设置它允许接收，在中心仓库输入：

git config receive.denyCurrentBranch ignore

　　关于这个bare仓库可以多谈几句，通过bare建立的.git仓库是没有工作区的，所以又称为裸仓库，通常用它作为中心仓库。


　　问题7：Git add或commit出现：“ fatal: Pathspec \'xxx\' is in submodule \'yyy\' 异常”

　　解决办法：碰到这个问题是开发某小哥自己在yyy文件夹里搞了一个git仓库，然后另一个小伙直接放到项目中了，结果两个git仓库相互作用，导致项目的git仓库无法添加xxx到项目中，OK，总之这是两个仓库，通常我们到GitHub去clone别人的代码也会碰到这类问题，需要做的很简单，删掉yyy下面的git仓库，并把当前项目git的cache中的yyy清空掉：

git rm -rf --cached yyy
git add .
git commit -m \'add something\'
git push origin master

 

　　一些经验分享：注意平时在多人操作同一个git仓库时候尽量用不同的分支，在合并代码的时候使用一个主分支即可，此外，如果你忘记了代码的更新状态，在push操作之前尽量先pull。

活动分支合入主分支时发生冲突

产生原因

平时基于活动分支开发，如果这个过程中为了修复bug而拉了一个bugfix分支，当bugfix分支开发完成并合入master分支后，如果bugfix分支和活动分支修改了相同的文件，则在活动分支合入master分支时就会产生冲突。

解决方法

  1. 从个人代码库（服务端）clone一个库到本地，即专门用于合并的个人工作库。（也可以用之前的个人工作库，但初学都容易混淆，建议单独clone一个。）
  2. 从主库的活动分支上pull最新的代码到本地。
  3. 从主库的master分支上pull最新的代码到本地。
  4. 此时会产生冲突，手工修复冲突，然后先commit到本地的个人工作库，再push到个人代码库（服务端）。
  5. 提交从个人工作库（服务端）到主库的MR（此时不会再有冲突），然后由Committer审核后将MR合入主库。