git

git

Git工作流程最佳实践总结

运维技术Rock 发表了文章 • 0 个评论 • 395 次浏览 • 2016-09-09 13:56 • 来自相关话题

Git作为一个目前非常流行的版本管理工具,深受开发者的喜爱。那么怎样才能将Git的作用发挥的更好呢?我根据实际的项目经验,归纳总结了以下Git工作流的最佳实践。这里所谓的最佳,是经过多次项目经验后,根据自身的情况总结出来的我认为最为合理的方案。
 
Git工作流的最佳实践方案包括如下四个步骤:

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

当我们开始针对一个task编码之前,首先第一步应该要创建一个新的branch,然后checkout到这个新的branch上开始编码。我们不应该直接在master上进行新的task的编码工作,尤其是在团队成员较多的情况下。团队的每个成员都应工作于自己新创建的branch上,而不会操作master分支,这样做的好处在于master始终处于一种“干净”的状态,不会因为多人的同时操作而造成过多的冲突,同时也降低了master被误操作的可能性。具体的操作如下://切换到master分支;
git checkout master
//拉取master远程分支的代码;
git pull origin master
//创建新的分支并切换到新的分支上。
git checkout -b <my branch name>

 

2. 在新建的分支上编码,push代码到远程分支上

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

首先看一下这个阶段Git工作的命令流,示例如下:
//创建新的branch后的第一天工作结束时,首先将改动的代码放入index区;
git add .
//然后提交代码到本地仓库;
git commit -m "The first commit message"//第二天开始工作前,切换到master分支;
git checkout master
//从master的远程分支拉取代码;
git pull origin master
//切换到task所在的本地分支;
git checkout <my branch name>
//将master上的最新的代码合并到当前分支上,这里的-i的作用是将我们 当前分支之前的commit压缩成为一个commit,这样做的好处在于当我们之后创建pull request并进行相应的code review的时候,代码的改动会集中在一个commit,使得code review更直观方便;
git rebase -i master 

//第二天工作结束之后,将第二天的改动放入index区;
git add .
//提交代码到当前branch的本地仓库;
git commit  -m "The second commit message"//第三天开始工作前,
git checkout master //同上第二天
git pull origin master //同上第二天
git checkout //同上第二天
git rebase -i master  //同上第二天

//第三天工作结束之后,
git add . //同上第二天
git commit  -m "The third commit message" //同上第二天..........
//最后,当task的所有编码完成之后,将代码push到远程分支。
git push --set-upstream origin <my branch name>通过以上的工作流可以看出,我们在完成task期间所有的代码都始终存放在我们新创建的branch的本地仓库上。只有当所有的编码工作完成之后,才会将最终的代码push到当前分支的远程仓库。这样做的好处在于,我们push到远程的代码,也就是之后会通过pull request被code review的代码,始终是针对一个单独task的完整代码,这将有利于之后code review的执行。不过这样做同时可能会存在一个缺点,那就是最终一次push的代码可能会非常庞大,这就要求我们对于task粒度的把握应该更合适。我们不应针对一个非常大的task创建branch,完成编码,而是应该尽可能的将task分解成一个个粒度较小的子task,进而针对子task创建branch完成编码的工作。这是一项非常有技巧的工作,需要丰富的实践经验,它也不是本节要讨论的内容,不再赘述。
 

3. 创建pull request, 进行code review

当所有的代码都已经被push到远程分支后,这时我们还不可以将代码合并到master上去,我们应该要做的是创建pull request。pull request的作用在于它可以使得代码在merge到master分支之前,能够被团队成员code review,从而提高代码的质量以及降低出错的概率。实际项目中我们使用jira来帮助我们创建相应的pull request,当然Github本身就具备创建pull request的功能。创建pull request的操作非常简单,无非就是点击创建pull request的按钮,填写comment信息,并输入可以进行code review的成员名称。当pull request创建完成之后,所有可以进行code review的团队成员都会收到邮件通知,并通过相应的pull request的链接查看代码的改动,从而完成code review的工作。这个步骤没有实际的Git指令的操作。
 

4. 合并代码到master,并删除之前创建的branch

当所有的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>//删除之前创建的分支。经过以上四个步骤之后,一个task的 Git的工作流就结束了。之后,我们可以愉快的开始下一个task了~~
 
文/Ifdef_Max(简书作者)
原文链接:http://www.jianshu.com/p/202de00f267f  查看全部
Git作为一个目前非常流行的版本管理工具,深受开发者的喜爱。那么怎样才能将Git的作用发挥的更好呢?我根据实际的项目经验,归纳总结了以下Git工作流的最佳实践。这里所谓的最佳,是经过多次项目经验后,根据自身的情况总结出来的我认为最为合理的方案。
 
Git工作流的最佳实践方案包括如下四个步骤:


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


当我们开始针对一个task编码之前,首先第一步应该要创建一个新的branch,然后checkout到这个新的branch上开始编码。我们不应该直接在master上进行新的task的编码工作,尤其是在团队成员较多的情况下。团队的每个成员都应工作于自己新创建的branch上,而不会操作master分支,这样做的好处在于master始终处于一种“干净”的状态,不会因为多人的同时操作而造成过多的冲突,同时也降低了master被误操作的可能性。具体的操作如下:
//切换到master分支;
git checkout master
//拉取master远程分支的代码;
git pull origin master
//创建新的分支并切换到新的分支上。
git checkout -b <my branch name>

 


2. 在新建的分支上编码,push代码到远程分支上


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

首先看一下这个阶段Git工作的命令流,示例如下:
//创建新的branch后的第一天工作结束时,首先将改动的代码放入index区;
git add .
//然后提交代码到本地仓库;
git commit -m "The first commit message"
//第二天开始工作前,切换到master分支;
git checkout master
//从master的远程分支拉取代码;
git pull origin master
//切换到task所在的本地分支;
git checkout <my branch name>
//将master上的最新的代码合并到当前分支上,这里的-i的作用是将我们 当前分支之前的commit压缩成为一个commit,这样做的好处在于当我们之后创建pull request并进行相应的code review的时候,代码的改动会集中在一个commit,使得code review更直观方便;
git rebase -i master 

//第二天工作结束之后,将第二天的改动放入index区;
git add .
//提交代码到当前branch的本地仓库;
git commit  -m "The second commit message"
//第三天开始工作前,
git checkout master //同上第二天
git pull origin master //同上第二天
git checkout //同上第二天
git rebase -i master  //同上第二天

//第三天工作结束之后,
git add . //同上第二天
git commit  -m "The third commit message" //同上第二天
..........
//最后,当task的所有编码完成之后,将代码push到远程分支。
git push --set-upstream origin <my branch name>
通过以上的工作流可以看出,我们在完成task期间所有的代码都始终存放在我们新创建的branch的本地仓库上。只有当所有的编码工作完成之后,才会将最终的代码push到当前分支的远程仓库。这样做的好处在于,我们push到远程的代码,也就是之后会通过pull request被code review的代码,始终是针对一个单独task的完整代码,这将有利于之后code review的执行。不过这样做同时可能会存在一个缺点,那就是最终一次push的代码可能会非常庞大,这就要求我们对于task粒度的把握应该更合适。我们不应针对一个非常大的task创建branch,完成编码,而是应该尽可能的将task分解成一个个粒度较小的子task,进而针对子task创建branch完成编码的工作。这是一项非常有技巧的工作,需要丰富的实践经验,它也不是本节要讨论的内容,不再赘述。
 


3. 创建pull request, 进行code review


当所有的代码都已经被push到远程分支后,这时我们还不可以将代码合并到master上去,我们应该要做的是创建pull request。pull request的作用在于它可以使得代码在merge到master分支之前,能够被团队成员code review,从而提高代码的质量以及降低出错的概率。实际项目中我们使用jira来帮助我们创建相应的pull request,当然Github本身就具备创建pull request的功能。创建pull request的操作非常简单,无非就是点击创建pull request的按钮,填写comment信息,并输入可以进行code review的成员名称。当pull request创建完成之后,所有可以进行code review的团队成员都会收到邮件通知,并通过相应的pull request的链接查看代码的改动,从而完成code review的工作。这个步骤没有实际的Git指令的操作。
 


4. 合并代码到master,并删除之前创建的branch


当所有的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>//删除之前创建的分支。
经过以上四个步骤之后,一个task的 Git的工作流就结束了。之后,我们可以愉快的开始下一个task了~~
 
文/Ifdef_Max(简书作者)
原文链接:http://www.jianshu.com/p/202de00f267f 

Git工作流程最佳实践总结

运维技术Rock 发表了文章 • 0 个评论 • 395 次浏览 • 2016-09-09 13:56 • 来自相关话题

Git作为一个目前非常流行的版本管理工具,深受开发者的喜爱。那么怎样才能将Git的作用发挥的更好呢?我根据实际的项目经验,归纳总结了以下Git工作流的最佳实践。这里所谓的最佳,是经过多次项目经验后,根据自身的情况总结出来的我认为最为合理的方案。
 
Git工作流的最佳实践方案包括如下四个步骤:

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

当我们开始针对一个task编码之前,首先第一步应该要创建一个新的branch,然后checkout到这个新的branch上开始编码。我们不应该直接在master上进行新的task的编码工作,尤其是在团队成员较多的情况下。团队的每个成员都应工作于自己新创建的branch上,而不会操作master分支,这样做的好处在于master始终处于一种“干净”的状态,不会因为多人的同时操作而造成过多的冲突,同时也降低了master被误操作的可能性。具体的操作如下://切换到master分支;
git checkout master
//拉取master远程分支的代码;
git pull origin master
//创建新的分支并切换到新的分支上。
git checkout -b <my branch name>

 

2. 在新建的分支上编码,push代码到远程分支上

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

首先看一下这个阶段Git工作的命令流,示例如下:
//创建新的branch后的第一天工作结束时,首先将改动的代码放入index区;
git add .
//然后提交代码到本地仓库;
git commit -m "The first commit message"//第二天开始工作前,切换到master分支;
git checkout master
//从master的远程分支拉取代码;
git pull origin master
//切换到task所在的本地分支;
git checkout <my branch name>
//将master上的最新的代码合并到当前分支上,这里的-i的作用是将我们 当前分支之前的commit压缩成为一个commit,这样做的好处在于当我们之后创建pull request并进行相应的code review的时候,代码的改动会集中在一个commit,使得code review更直观方便;
git rebase -i master 

//第二天工作结束之后,将第二天的改动放入index区;
git add .
//提交代码到当前branch的本地仓库;
git commit  -m "The second commit message"//第三天开始工作前,
git checkout master //同上第二天
git pull origin master //同上第二天
git checkout //同上第二天
git rebase -i master  //同上第二天

//第三天工作结束之后,
git add . //同上第二天
git commit  -m "The third commit message" //同上第二天..........
//最后,当task的所有编码完成之后,将代码push到远程分支。
git push --set-upstream origin <my branch name>通过以上的工作流可以看出,我们在完成task期间所有的代码都始终存放在我们新创建的branch的本地仓库上。只有当所有的编码工作完成之后,才会将最终的代码push到当前分支的远程仓库。这样做的好处在于,我们push到远程的代码,也就是之后会通过pull request被code review的代码,始终是针对一个单独task的完整代码,这将有利于之后code review的执行。不过这样做同时可能会存在一个缺点,那就是最终一次push的代码可能会非常庞大,这就要求我们对于task粒度的把握应该更合适。我们不应针对一个非常大的task创建branch,完成编码,而是应该尽可能的将task分解成一个个粒度较小的子task,进而针对子task创建branch完成编码的工作。这是一项非常有技巧的工作,需要丰富的实践经验,它也不是本节要讨论的内容,不再赘述。
 

3. 创建pull request, 进行code review

当所有的代码都已经被push到远程分支后,这时我们还不可以将代码合并到master上去,我们应该要做的是创建pull request。pull request的作用在于它可以使得代码在merge到master分支之前,能够被团队成员code review,从而提高代码的质量以及降低出错的概率。实际项目中我们使用jira来帮助我们创建相应的pull request,当然Github本身就具备创建pull request的功能。创建pull request的操作非常简单,无非就是点击创建pull request的按钮,填写comment信息,并输入可以进行code review的成员名称。当pull request创建完成之后,所有可以进行code review的团队成员都会收到邮件通知,并通过相应的pull request的链接查看代码的改动,从而完成code review的工作。这个步骤没有实际的Git指令的操作。
 

4. 合并代码到master,并删除之前创建的branch

当所有的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>//删除之前创建的分支。经过以上四个步骤之后,一个task的 Git的工作流就结束了。之后,我们可以愉快的开始下一个task了~~
 
文/Ifdef_Max(简书作者)
原文链接:http://www.jianshu.com/p/202de00f267f  查看全部
Git作为一个目前非常流行的版本管理工具,深受开发者的喜爱。那么怎样才能将Git的作用发挥的更好呢?我根据实际的项目经验,归纳总结了以下Git工作流的最佳实践。这里所谓的最佳,是经过多次项目经验后,根据自身的情况总结出来的我认为最为合理的方案。
 
Git工作流的最佳实践方案包括如下四个步骤:


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


当我们开始针对一个task编码之前,首先第一步应该要创建一个新的branch,然后checkout到这个新的branch上开始编码。我们不应该直接在master上进行新的task的编码工作,尤其是在团队成员较多的情况下。团队的每个成员都应工作于自己新创建的branch上,而不会操作master分支,这样做的好处在于master始终处于一种“干净”的状态,不会因为多人的同时操作而造成过多的冲突,同时也降低了master被误操作的可能性。具体的操作如下:
//切换到master分支;
git checkout master
//拉取master远程分支的代码;
git pull origin master
//创建新的分支并切换到新的分支上。
git checkout -b <my branch name>

 


2. 在新建的分支上编码,push代码到远程分支上


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

首先看一下这个阶段Git工作的命令流,示例如下:
//创建新的branch后的第一天工作结束时,首先将改动的代码放入index区;
git add .
//然后提交代码到本地仓库;
git commit -m "The first commit message"
//第二天开始工作前,切换到master分支;
git checkout master
//从master的远程分支拉取代码;
git pull origin master
//切换到task所在的本地分支;
git checkout <my branch name>
//将master上的最新的代码合并到当前分支上,这里的-i的作用是将我们 当前分支之前的commit压缩成为一个commit,这样做的好处在于当我们之后创建pull request并进行相应的code review的时候,代码的改动会集中在一个commit,使得code review更直观方便;
git rebase -i master 

//第二天工作结束之后,将第二天的改动放入index区;
git add .
//提交代码到当前branch的本地仓库;
git commit  -m "The second commit message"
//第三天开始工作前,
git checkout master //同上第二天
git pull origin master //同上第二天
git checkout //同上第二天
git rebase -i master  //同上第二天

//第三天工作结束之后,
git add . //同上第二天
git commit  -m "The third commit message" //同上第二天
..........
//最后,当task的所有编码完成之后,将代码push到远程分支。
git push --set-upstream origin <my branch name>
通过以上的工作流可以看出,我们在完成task期间所有的代码都始终存放在我们新创建的branch的本地仓库上。只有当所有的编码工作完成之后,才会将最终的代码push到当前分支的远程仓库。这样做的好处在于,我们push到远程的代码,也就是之后会通过pull request被code review的代码,始终是针对一个单独task的完整代码,这将有利于之后code review的执行。不过这样做同时可能会存在一个缺点,那就是最终一次push的代码可能会非常庞大,这就要求我们对于task粒度的把握应该更合适。我们不应针对一个非常大的task创建branch,完成编码,而是应该尽可能的将task分解成一个个粒度较小的子task,进而针对子task创建branch完成编码的工作。这是一项非常有技巧的工作,需要丰富的实践经验,它也不是本节要讨论的内容,不再赘述。
 


3. 创建pull request, 进行code review


当所有的代码都已经被push到远程分支后,这时我们还不可以将代码合并到master上去,我们应该要做的是创建pull request。pull request的作用在于它可以使得代码在merge到master分支之前,能够被团队成员code review,从而提高代码的质量以及降低出错的概率。实际项目中我们使用jira来帮助我们创建相应的pull request,当然Github本身就具备创建pull request的功能。创建pull request的操作非常简单,无非就是点击创建pull request的按钮,填写comment信息,并输入可以进行code review的成员名称。当pull request创建完成之后,所有可以进行code review的团队成员都会收到邮件通知,并通过相应的pull request的链接查看代码的改动,从而完成code review的工作。这个步骤没有实际的Git指令的操作。
 


4. 合并代码到master,并删除之前创建的branch


当所有的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>//删除之前创建的分支。
经过以上四个步骤之后,一个task的 Git的工作流就结束了。之后,我们可以愉快的开始下一个task了~~
 
文/Ifdef_Max(简书作者)
原文链接:http://www.jianshu.com/p/202de00f267f 
Git是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。