git管理项目

951 查看

git管理项目

私有小团队

小团队

  • 一个私有项目,与你一起协作的还有另外一到两位开发者

  • 这里说私有,是指源代码不公开,其他人无法访问项目仓库

  • 你和其他开发者则都具有推送数据到仓库的权限。

开发管理过程Demo

初始化工程
  1. 搭建项目框架,设置master分支保护(repository:john@githost:simplegit.git)

  • 由项目经理搭建好基础框架,提交到master分支,并建立develop分支(此时develop和master是一样的),然后设置分支保护(只能读,不能写)

  • 如下图

  1. 开发人员John和Jess

    > 1. 假设现在有两名开发人员,都具有推送数据的权限(角色为developer)
    > 2. clone master分支到本地
    > 3. 新建自己的分支(developer_john和developer_jess),切换到自己的分支
    > 4. 进行各自的代码开发
    
john和jess各自开始开发
  1. John's Machine

$ git clone john@githost:simplegit.git

Initialized empty Git repository in /home/john/simplegit/.git/
....

$ git checkout -b developer_john 见John_newbranch_develop_johnjpg

$ vim login.java

$ git add --all

$ git commit -am 'add login.java'

  • [developer__john fbff5] add login.java

  • 1 files changed, 1 insertions(+), 0 deletions(-)

  • ....

见John_commit_develop_johnjpg

John_newbranch_develop_john.jpg


John_commit_develop_john.jpg

  1. Jess's Machine

$ git clone john@githost:simplegit.git

  • Initialized empty Git repository in /home/john/simplegit/.git/

  • ....

$ git checkout -b developer_jess 见Jess_newbranch_develop_jessjpg

$ vim register.java

$ git add --all

$ git commit -am 'add register.java'

  • [developer__jess b9801] add register.java

  • 1 files changed, 1 insertions(+), 0 deletions(-)

  • ....

见Jess_commit_develop_jessjpg


Jess_newbranch_develop_jessjpg

Jess_newbranch_develop_jessjpg

john开发完成了login模块

$ git checkout develop //切换到develop分支

$ git merge developer_john //合并developer_john到develop分支
//见john_merge_develop_john

$ git push origin develop //提交到服务器 见server


john_merge_develop_john

server

jess开发完成了register模块

$ git checkout develop //切换到develop分支

$ git merge developer_jess //合并developer_jess到develop分支 见jess_merge_develop_jess

$ git push origin develop //提交到服务器

  • To john@githost:simplegit.git

  • ! [rejected] master -> master (non-fast forward)

  • error: failed to push some refs to 'john@githost:simplegit.git'

  • .....

$ git fetch origin 见fetch
$ git merge developer_jess 见fetch_merge


jess_merge_develop_jess(what is fast-forward?相信使用过git的人经常会碰到.当你push成功了,提示fast-forward)

fetch

fetch_merge

分支管理的艺术

  • GIT,在技术层面上,绝对是一个无中心的分布式版本控制系统,但在管理层面上,我建议你保持一个中心版本库。毕竟从它诞生之日起,就开始管理了linux内核(其中包含了数百万名开源贡献者)。

  • 我建议,一个中心版本库(我们叫它origin)至少包括两个分支,即“主分支(master)”和“开发分支(develop)”

  • 要确保:团队成员从主分支(master)获得的都是处于可发布状态的代码,而从开发分支(develop)应该总能够获得最新开发进展的代码。

  • 在一个团队开发协作中,我建议,要有“辅助分支”的概念。

  • “辅助分支”,大体包括如下几类:功能分支(前缀feature/)、可发布版本分支(前缀release/)、修复补丁分支(前缀hotfix/),版本标签(前缀tag/)等等。

  • “辅助分支”的最大特点就是“生命周期十分有限”,完成使命后即可被清除。

  • 我建议至少还应设置三类“辅助分支”,我们称之为“Feature branches”,“Release branches”,“Hotfix branches”。

至此,我们形成了如下这张最重要的组织组,包含了两个粗体字分支(master/develop)和三个细体字分支(feature/release/hotfixes)。

  • “Feature branches”,起源于develop分支,最终也会归于develop分支

  • “Feature branches”常用于开发一个独立的新功能,且其最终的结局必然只有两个,其一是合并入“develop”分支,其二是被抛弃。最典型的“Fearture branches”一定是存在于团队开发者那里,而不应该是“中心版本库”中。
    git checkout -b myfeature develop

  • 合并feature分支到develop分支
    git checkout devleop

git merge --no-ff myfeature

(--no-ff,即not fast forward,其作用是:要求git merge即使在fast forward条件下也要产生一个新的merge commit)(此处,要求采用--no-ff的方式进行分支合并,其目的在于,希望保持原有“Feature branches”整个提交链的完整性)

git branch -d myfeature
git push origin develop

  • “Release branch”,起源于develop分支,最终归于“develop”或“master”分支。这类分支建议命名为“release-*”

  • “Relase branch”通常负责“短期的发布前准备工作”、“小bug的修复工作”、“版本号等元信息的准备工作”。与此同时,“develop”分支又可以承接下一个新功能的开发工作了。

  • “Release branch”产生新提交的最好时机是“develop”分支已经基本到达预期的状态,至少希望新功能已经完全从“Feature branches”合并到“develop”分支了。

  • 创建“Release branches”

git checkout -b release-1.2 develop

  • 在一段短时间内,在“Release branches”上,我们可以继续修复bug。在此阶段,严禁新功能的并入,新功能应该是被合并到“develop”分支的。

  • 经过若干bug修复后,“Release branches”上的代码已经达到可发布状态,此时,需要完成三个动作:第一是将“Release branches”合并到“master”分支,第二是一定要为master上的这个新提交打TAG(记录里程碑),第三是要将“Release branches”合并回“develop”分支。

git checkout master
git merge --no-ff release-1.2
git tag -a 1.2(使用-u/-s/-a参数会创建tag对象,而非软tag)
git checkout develop
git merge --no-ff release-1.2
git branch -d release-1.2

  • “Hotfix branches”源于“master”,归于“develop”或“master”,通常命名为“hotfix-*”

  • “Hotfix branches”类似于“Release branch”,但产生此分支总是非预期的关键BUG。

  • 建议设立“Hotfix branches”的原因是:希望避免“develop分支”新功能的开发必须为BUG修复让路的情况。

  • 建立“Hotfix branches”

git checkout -b hotfix-1.2.1 master

  •  BUG修复后,需要将“Hotfix branches”合并回“master”分支,同时也需要合并回“develop”分支,方法是:

git checkout mastergit merge --no-ff hotfix-1.2.1
git tag -a 1.2.1
git checkout develop
git merge --no-ff hotfix-1.2.1
git branch -d hotfix-1.2.1

总结

还记得文章开始时的那张大图么,我建议你把这幅大图从这里下载下来,打印出来,贴在你写字台的墙壁上,好处不言而喻。