赞
踩
工作流就是开发模式。例如,不同的开发人员将代码编写完毕之后怎么汇总合并,项目上线之后的后续功能开发,代码测试以及出现BUG怎么紧急修复等问题都是属于开发模式的范畴,也就是项目的工作流。
目前,大多数企业都借助Git来设计工作流。
集中式工作流是开发者将自己开发完毕的代码推送到统一的远程仓库,由此完成协作。一般适合变动不大的小项目。
功能分支工作流是集中式工作流的进一步拓展,依据功能来创建分支,编写完之后pull request,然后将功能分支合并到主分支上。适合分工明确、规模较小的项目。
而本文将着重介绍Git Flow工作流与Forking工作流,这两个也是业界常用的开发模式。
Git Flow工作流是企业用的比较多的开发模式,也是非开源项目常用的开发模式。Git Flow是功能分支开发模式的进一步拓展。 不单单开拓出了功能分支(feature)、还有增加了开发分支(develop)、修复分支(hotfix)以及release分支。
下面介绍一下几个分支的作用。
各个分支的协作如下:
Git Flow工作流适合团队稳定,规模较大的项目,小项目不建议使用。Git Flow模式较为健壮,使用较多。
我们可以通过实践来看看Git Flow工作流的过程。
#1.创建一个常驻分支 git checkout -b develop master #2.新建功能分支 git checkout -b feature/v1 develop #3.开发功能 vi main。go #4.功能代码提交到feature git commit -a -m "test-v1'" #5.本地feature推送到远程 git push origin feature/test-v1 #6.pull request and code review #7.合并到develop分支 git checkout develop git merge --no-ff feature/test-v1 #8.创建release并测试 git checkout -b release/v1.0.0 develop go build -v . # 构建后,部署二进制文件,并测试 #9.如果测试不成功,需要基于release修改 #10.测试完成后合并到develop和master git checkout develop git merge --no-ff release/v1.0.0 git checkout master git merge --no-ff release/v1.0.0 git tag -a v1.0.0 -m "add test-v1" # 打 tag #11.删除feature git branch -d feature/test-v1 #12.如果线上出现了紧急bug,需要记住hotfit修复 git checkout -b hotfix/print-error master #从 master 建立 hotfix 分支 vi main.go # 修复 bug, git commit -a -m 'fix print message error bug' git checkout develop # 切换到 develop 分支合并hotfix git merge --no-ff hotfix/print-error git checkout master #切换到 master 分支合并hotfix git merge --no-ff hotfix/print-error git tag -a v0.1.2 -m "fix log bug" # 打 tag go build -v . git branch -d hotfix/print-error # 修复好后删除
前面介绍了Git Flow工作流,是适用于非开源项目的工作流,这里介绍适合于开源项目的工作流,Forking模式。(如果想给开源项目贡献代码,也可以看看这部分内容)
基于Git的Forking就是拷贝一份远程仓库的代码到自己的代码库,然后进行相应的开发。开发完成之后,推送到远程仓库并提交一个PR(pull request)给远程仓库的作者。作者收到PR之后,可以进行code review,并且可以针对PR评论。code review通过之后,提交的代码就会合并进远程仓库。这样就完成了远程仓库的协助开发。
一般Forking模式应用在开源项目,支持贡献代码,协助开发。社区中一般基于Git使用这种开发模式。
git clone https://github.com/······
cd ······
git remote add upstream https://github.com/xxx
git remote set-url --push upstream no_push
git remote -v # Confirm that your remotes make sense
origin https://github.com/······ (fetch)
origin https://github.com/······ (push)
upstream https://github.com/xxx (fetch)
upstream https://github.com/xxx (push)
git fetch upstream
git checkout master
git rebase upstream/master
git checkout -b feature/mycode
git fetch upstream #commit前需要再次同步
git rebase upstream/master
git add <file>
git status
git commit
git rebase -i origin/master
git push -f origin feature/mycode
等作者那边通过了就可以了,需要注意作者在PR下的留言.
补充拓展
在提交的时候,可能会有一堆不同版本的commit,但是一般只有一个commit或者两三个commit是我们最终需要的。为了便于维护与阅读,可以使用git rebase来合并我们的commit;
#自动合并commit
git commit --fixup
git rebase -i --autosquash
或者,可以撤销之前的提交,重新建立最后的一次提交。
git reset HEAD~n #(n表示几次提交)
git add .
git commit -am "Here's the bug fix that closes #28"
git push --force
以上就是Forking工作流的介绍,可以看到,这个模式适用于开源项目,而且开发团队不那么固定的项目。如果有衍生代码版本的需求,forking是优选的模式。
以上就是关于Git工作流的介绍,如果有什么错误的,请联系我改正。
参考
项目参考:https://github.com/marmotedu
(@colin)
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。