Git Workflow最佳实践
2016-09-12 19:26
295 查看
Git作为一个当前非常流行的版本管理工具,深受广大开发者的青睐。那么怎样才能将Git的作用发挥的更好呢?本人根据实际项目开发中的经验,归纳总结了以下Git工作流的最佳实践。欢迎大家拍砖!
强烈不建议直接在master上进行新的task的开发,尤其是在团队成员较多的情况下。团队的每个成员都应工作于自己新创建的branch上,这样做的好处在于master始终处于一种“整洁”的状态,不会因为多人的同时操作而造成过多的冲突,同时也降低了master被误操作的可能性。
具体的Git操作命令如下:
首先看一下这个阶段Git工作的命令流,示例如下:
git rebase -i master 命令将master上的最新的代码合并到当前分支上,这里的-i的作用是将我们 当前分支之前的commit压缩成为一个commit,这样做的好处在于当我们之后创建pull request并进行相应的code review的时候,代码的改动会集中在一个commit,使得code review更直观方便。
合并完master上的最新代码后,就可以继续开发了。当天开发结束时,将更新的代码提交到本地仓库,命令如下:
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非必选,可以直接跳过 进入第四步。
命令如下:
如果嫌敲命令比较麻烦的话,可以直接点击 GitHub/GitLab 网页上的Merge按钮来执行代码合并。
至此,一个task的 Git的工作流就结束了。
前提条件
本人日常开发用到:Git + GitHub/GitLab1. 根据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的工作流就结束了。
相关文章推荐
- Git 在团队中的最佳实践--如何正确使用Git Flow
- 【C#编程最佳实践 二】git操作实践
- GIT 分支最佳实践
- Git 快速入门与最佳实践
- Git的最佳实践git-flow
- Git 在团队中的最佳实践--如何正确使用Git Flow
- Git 最佳实践:分支管理
- Git 在团队中的最佳实践--如何正确使用Git Flow
- 版本控制之最佳实践(Git版)
- Git 在团队中的最佳实践--如何正确使用Git Flow
- Git 分支管理最佳实践
- Git Flow,Git团队协作最佳实践
- 【GIT】Git Flow最佳实践
- Git详解之十 分支管理最佳实践
- Git 最佳实践:分支管理
- Git 在团队中的最佳实践--如何正确使用Git Flow
- git分支的管理策略最佳实践
- Git Flow 在团队中的最佳实践 -- SourceTree的使用
- 版本控制之最佳实践(Git版)
- Git 在团队中的最佳实践--如何正确使用Git Flow