项目组GIT操作规范

本文主要是介绍项目组GIT操作规范，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

分支规范

在开发过程中，一般会存在以下几种分支：

• main分支(master)
  master为主分支，也是用于部署生产环境的分支，一般由 dev 以及 fixbug分支合并，任何时间都不能直接修改代码。
• dev分支
  develop 为开发分支，始终保持最新完成以及bug修复后的代码。一般开发新功能时，feature 分支都是基于 dev 分支下创建的。
• feature-[功能名称/版本信息]
  feature为需求分支，以 dev 分支为基础创建 feature 分支。每个开发人员基于feature分支，创建自己的开发分支。
• fixbug-[bug编号]
  线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 fixbug分支，修复完成后，需要合并到 master 分支和 dev 分支。

注意：

• 使用git pull定期从远程仓库拉取更新并与本地分支同步，避免出现长时间不更新导致合并时产生大量冲突的情况。
• 合并代码前，运行git fetch获取远程分支最新状态，然后使用git merge或git rebase进行合并，并解决可能发生的冲突。
• 定期清理不再需要的功能分支，完成并合并后删除它们以保持分支列表清晰。

常用分支命令

git branch -r  #远程仓库分支
git branch -a  #所有分支列表
git branch #新分支名称
git checkout branchName #切换分支
#创建分支并切换
git checkout -b branchName#删除本地分支，当分支被推送并合并到远程分支后-d才会删除本地分支
git branch -d localBranchName
#删除远程分支
git push origin --delete remoteBranchName#推送本地分支到远程分支（远程暂时无对应分支）
git push origin localBranch:remoteBranch
#拉取远程分支到本地（在本地创建分支并自动切换到新分支并且与远程分支建立映射关系）
git checkout -b localBranch origin/remoteName

Commit 提交规范

1. 提交的日志格式
   每次git提交日志格式为： 类型:描述
   类型：用于说明 commit 的类别，只允许使用下面7个标识。

   • feat：新功能
   • fix：修补bug
   • docs：修改文档
   • style： 格式化代码结构，没有逻辑上的代码修改
   • refactor：重构，即不是新增功能，也不是修改bug的代码变动，比如重命名变量
   • test：增加测试代码，单元测试一类的，没有生产代码的变更
   • chore：构建过程或辅助工具的变动（不会影响代码运行）

   描述：是本次commit的描述，说明白本次提交都干了些啥
   例如：

git commit -m "feat: 新增用户详情页接口"
git commit -m "fix: 修复用户注册时电话号码校验逻辑问题" 
git commit -m "docs: 新增项目Readme 文档"

2. 提交频率
   • 提交粒度按照功能点进行提交，切记不要一直不提交，积攒一大堆代码再提交；

更新、合并规范

原则：

1. 下游分支更新上游分支代码用rebase；
2. 上游分支合并下游分支代码用merge；
3. 更新本分支代码用--rebase (如果本分支有多人共同使用开发的时候)；
   这样可以消除自动产生的无用merge记录，有利于后续查看开发记录。

下游分支在更新上游分支代码的时候，如果使用merge,会产生一条无用的合并记录，比较影响查看历史，使用rebase则不会。

分场景介绍

目前有个xx需求，由a、b两名同事进行开发分支说明（建立个人开发分支是为了方便做代码review）

• master：主分支
• dev：测试分支
• Feature--xx：订单详情需求分支
• Feature--xx-a：订单详情a开发分支
• Feature--xx-b：订单详情b开发分支

master主分支内容

当前所有分支都基于master分支进行创建，内容与master分支一致。

场景一：feature--xx分支代码有个更新，本地feature--xx更新代码。

远程分支新增一个类，如下

# 目前代码处于feature--xx分支，且都已经本地提交（没提交的可以使用暂存功能） 同步远程库代码变动 
$ git fetch origin 
# 使用rebase进行代码更新代码
$ git pull origin feature--xx --rebase

备注：

git fetch #拉取代码，需要使用git merge进行合并
git pull #拉取代码，会直接将本地代码更新至远程仓库里面最新的版本
# 也可使用IDEA自带功能(具体不再详述)

场景二：feature--xx分支代码有了新代码的更新，a要合并代码。

梳理下思路：

1. feature--xx-a更新远程分支代码(不更新也行，因为只有a在使用)；
2. 合并origin/feature-xx分支代码，有冲突解决冲突，没有冲突将代码push到服务器；
3. 发起合并。

远程feature-xx分支新增输出内容

操作步骤

# 假设所有代码已经都提交，无需进行提交或者暂存代码的操作； 
$ git checkout feature--xx-a 
# 同步远程库代码变动 
$ git fetch origin 
# 使用rebase进行代码合并（合并上层分支到下层） 
$ git rebase origin/feature--xx 
# 如果此时有冲突，解决冲突，并将解决完冲突的代码提交，在执行rebase 即可 
$ git rebase --continue 

合并后如下

# 合并完之后，push代码，push完之后，a的代码已经到远程feature-xx-a分支了 
$ git push  # 此时，如果需要进行代码审核，发起一个合并请求即可； 
# 如果不需要进行代码审核，后续操作就是合并到feature--xx分支 
# 切换分支,并更新代码 
$ git checkout feature--xx 

$ git pull --rebase  
# 合并张三分支代码，并推送远程 
$ git merge feature--xx-a 

#  git push --set-upstream origin feature--xx
$ git push

分支使用及发版流程

负责人排定发行版计划，并执行发行版控制，注意前/后端的协同。测试版本可根据开发计划，拆解生产版本任务，组织阶段测试。

提测通过后拉分支继续开发、版本内有bug修复后合到已提交版本重新发版。具体流程如下：

这篇关于项目组GIT操作规范的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---