Git Workflow最佳实践

Git作为一个当前非常流行的版本管理工具,深受广大开发者的青睐。那么怎样才能将Git的作用发挥的更好呢?本人根据实际项目开发中的经验,归纳总结了以下Git工作流的最佳实践。欢迎大家拍砖!

前提条件

本人日常开发用到:Git + GitHub/GitLab

1. 根据task创建对应的develop branch

当我们接到一个新的task,首先第一步要做的就是创建一个新的开发分支(develop branch),然后checkout到这个新的branch上开始开发。
强烈不建议直接在master上进行新的task的开发,尤其是在团队成员较多的情况下。团队的每个成员都应工作于自己新创建的branch上,这样做的好处在于master始终处于一种“整洁”的状态,不会因为多人的同时操作而造成过多的冲突,同时也降低了master被误操作的可能性。

具体的Git操作命令如下:

$ git checkout master //切换到master分支;
$ git pull origin master  //拉取master远程分支的代码;
$ git checkout -b <my branch name> //创建新的分支并切换到该分支上。

2.在新的develop分支上开发

develop分支创建完毕之后,我们就可以开始在develop分支上进行开发了。这是我们完成task的最主要的阶段,绝大部分的工作在此阶段完成,同时它应该也是持续时间最长的阶段。它的主要任务就是完成task的需求开发工作,并最终将代码push到当前分支对应的远程分支上去。

首先看一下这个阶段Git工作的命令流,示例如下:

2.1 第一天
$ git add . //第一天工作结束时,首先将改动的代码放入暂存区;
$ git commit  -m "The first commit message" //提交代码到本地仓库;
2.2 日常开发

以后每天开始工作前,先合并master分支代码到当前分支上,命令如下:

$ git checkout master 
$ git pull origin master  //从master的远程分支拉取代码;
$ git checkout <my branch name> //切换到task所在的本地分支;
$ git rebase -i master  //合并代码


git rebase -i master 命令将master上的最新的代码合并到当前分支上,这里的-i的作用是将我们 当前分支之前的commit压缩成为一个commit,这样做的好处在于当我们之后创建pull request并进行相应的code review的时候,代码的改动会集中在一个commit,使得code review更直观方便。


合并完master上的最新代码后,就可以继续开发了。当天开发结束时,将更新的代码提交到本地仓库,命令如下:

$ git add . //当天工作结束之后,将改动放入暂存区;
$ git commit  -m "daily commit message" //提交代码到本地仓库;
2.3 push代码到远程分支

最后,当task的所有编码完成之后,将本地仓库中的代码push到远程分支上,命令如下:

$ git push --set-upstream origin <my branch name>


3.创建pull request

当所有的代码都已经被push到远程分支后,这时我们还不可以将代码合并到master上去,我们应该要做的是创建pull request。
pull request的作用在于它可以使得代码在merge到master分支之前,能够被团队成员code review,从而提高代码的质量以及降低出错的概率。

GitHub/GitLab本身就具备创建pull request的功能。创建pull request的操作非常简单,无非就是点击创建pull request的按钮,填写comment信息,并输入可以进行code review的成员名称。当pull request创建完成之后,所有可以进行code review的团队成员都会收到邮件通知,并通过相应的pull request的链接查看代码的改动,从而完成code review的工作。这个步骤没有实际的Git指令的操作。


这一步中的code review非必选,可以直接跳过 进入第四步。

4. 合并代码到master

当所有的reviewer都结束了code review,且都已经将pull request标注为approved状态的时候,我们就可以将branch合并到master上去,并最终push到远程master分支。
命令如下:

$ git checkout master //切换到master分支;
$ git merge <my branch name>//合并之前创建的分支的代码到master分支上;
$ git push origin master//将master的代码push到master的远程分支;
$ git branch -d <my branch name>//删除之前创建的分支。

如果嫌敲命令比较麻烦的话,可以直接点击 GitHub/GitLab 网页上的Merge按钮来执行代码合并。


至此,一个task的 Git的工作流就结束了。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Git workflow 是指在使用 Git 版本控制时,团队协作开发时所采用的工作流程。常见的 Git workflow 包括集中式工作流、功能分支工作流Gitflow 工作流、Forking 工作流等。 1. 集中式工作流(Centralized Workflow):团队成员直接在主分支(通常是 master 或 main)上进行开发,每个开发者都有自己的本地分支,完成开发后将本地分支合并到主分支中。 2. 功能分支工作流(Feature Branch Workflow):每个功能或任务都在独立的分支上进行开发,开发完成后合并到主分支。这种工作流程使得团队成员可以并行开发多个功能,减少代码冲突。 3. Gitflow 工作流Gitflow 是一种在功能分支工作流基础上扩展出的工作流程,主要区别是引入了额外的分支来管理特性开发、发布和维护等不同阶段。它包括主分支(master 或 main)、开发分支(develop)、特性分支(feature)、发布分支(release)、修复分支(hotfix)等。 4. Forking 工作流:适用于开源项目,每个贡献者通过 Fork 项目得到自己的独立仓库,在自己的仓库中进行开发,然后通过 Pull Request 将修改提交给原项目。原项目的维护者可以审查和合并这些提交。 这些只是一些常见的 Git workflow,实际上还有很多其他的变种和组合。选择适合团队的工作流程取决于项目的规模、团队的协作方式和开发流程等因素。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值