Git工作流模式及命令的使用讲解

目录

• Git的工作方式
• 集中式工作流
• 功能分支工作流
• Gitflow工作流
• 维护分支
• 工作流程
• Forking工作流
• Pull Request

Git的工作方式

分为集中式工作流、功能分支工作流、Gitflow工作流和Forking，其中集中式工作流和功能分支工作流是已经使用过的，Gitflow和Forking两种工作流暂时没有使用过。

集中式工作流

一个远程仓库，一个主分支master，团队每个成员都有一个本地仓库，在本地仓库中进行代码的编辑、暂存和提交工作：

git add  或 git add .>
//`some file`代表要暂存的文件，`.`代表工作目录下的所有文件
gie commit -m "一些描述"
//提交文，描述指的是本次提交修改了什么功能或者修改了什么bug，方便以后的查看
git push -u origin master
//-u选项设置本地分支去跟踪远程对应的分支。设置好跟踪的分支后，就可以使用git push命令省去指定推送分支的参数
//发布本地仓库到远程的中央仓库中，origin是远程仓库名，master是参数告诉Git的分支，master代表主分支，当然分支可以不是主分支

注意:在一种情况下push命令会出错，即如果小明第一次发布代码到远程仓库，此时小红在 本地开发自己的功能，那么在小红push自己的本地库到远程的时候会报错，原因是小红的本地库和远程库有分歧，需要先pull远程库到本地，与本地库合并之后再push到远程库。

功能分支工作流

在集中式工作流的基础上，为各个新功能分配一个专门的分支来开发，即在master主分支外在创建一个分支，程序员开发的新功能全部push到此分支上，等到功能成熟的时候再把此分支合并到主分支master上

git checkout -b newbranch master
//checkout代表创建切换带新分支newbranch
//-b代表如果新分支不存在则会创建一个新分支
//最后的master代表新分支是基于主分支创建的

新分支创建之后，对其的编辑、暂存和提交工作与之前一样，对其push的命令变为

git push origin newbranch

等到新功能完善之后，通过以下命令：

git checkout mastergit pullgit pull origin newbranchgit push

首先git checkout master切换到主分支，然后执行git pull把本地仓库的主分支上传到远程库，再执行git pull origin newbranch保证合并newbranch分支和已经和远程一致的本地master分支，你可以使用简单git merge newbranch命令，但前面的命令可以保证总是最新的新功能分支。 最后把更新的master分支重新push到远程库。

Gitflow工作流

Gitflow工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。
除了有master主分支（用于存储正式发布的历史）外，还有一个作为功能集成分支的develop分支。当初始化完成后，某个程序员想要开发一个性能，并不是直接从master分支上拉出新分支，而是使用develop分支作为父分支，当新功能完成后，再合并会父分支，新功能的提交并不与master分支直接交互。

一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。

维护分支

维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。

工作流程

为master分支配套一个develop分支

git branch develop
git push -u origin develop

以后这个分支将会包含了项目的全部历史，而master分支将只包含了部分历史。其它开发者这时应该克隆中央仓库，建好develop分支的跟踪分支：

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

现在每个开发都有了这些历史分支的本地拷贝。
小红和小明开团队成员始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于master分支，而是应该基于develop分支：

git checkout -b some-feature develop

他们用老套路添加提交到各自功能分支上：编辑、暂存、提交：

git status
git add 
git commit

添加了提交后，功能OK了之后，如果团队使用Pull Requests，这时候可以发起一个用于合并到develop分支。 否则她可以直接合并到她本地的develop分支后push到中央仓库：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一条命令在合并功能前确保develop分支是最新的。注意，功能决不应该直接合并到master分支。 冲突解决方法和集中式工作流一样。

Forking工作流

分布式工作流，充分利用了Git在分支和克隆上的优势，既可以管理大团队的开发者（developer）和接受不信任贡献者（contributor）的提交。这种工作流使得每个开发者都有一个服务端仓库（此仓库只有自己可以push，但是所有人都可以pull修改），每个程序员都push代码到自己的服务端仓库，但不能push到正式仓库，只有项目维护者才能push到正式仓库，这样项目维护者可以接受任何开发者的提交，但无需给他正式代码库的写权限。
这种工作流适合网上开源社区的开源项目，大家统一对项目做贡献，但是有一个人或一个团队作为开发者来管理项目，所有的贡献者的代码由开发者审核，其功能完善之后再由开发者push到正式仓库中。

Pull Request

Pull Request是一个为讨论提交功能的专门论坛，是一个友好的web界面（在个人github项目中也有这样一个选项），大家在其中做一些Code Review的工作，把结果反馈到Pull Request中，还可以在其中push新的提交微调功能，等到讨论结束后醒目维护者合并所有的功能到官方仓库中，关闭Pull Request。

发起一个Pull Request，就是要请求另一个开发者来pull自己仓库的一个分支到它的仓库中，因此需要提供四个信息：源仓库、源分支、目的仓库、目的分支。

Pull Request可以用于上述除了集中式工作流的其他三种工作流，因为其要求要么分支不同，要么仓库不同，而集中式工作流只有一个仓库，一个master分支。

例：

在功能分支工作流中使用Pull Request

功能分支工作流只有一个公开的仓库，所以Pull Request的目的仓库和源仓库总是同一个。 通常开发者会指定他的功能分支作为源分支，master分支作为目的分支。

收到Pull Request后，项目维护者要决定如何做。如果功能没问题，就简单地合并到master分支，关闭Pull Request。但如果提交的变更有问题，他可以在Pull Request中反馈。之后新加的提交也会评论之后接着显示出来。

在功能还没有完全开发完的时候，也可能发起一个Pull Request。 比如开发者在实现某个需求时碰到了麻烦，他可以发一个包含正在进行中工作的Pull Request。 其它的开发者可以在Pull Request提供建议，或者甚至直接添加提交来解决问题。

参考：http://shouce.jb51.net/gitbook/Distributed-Git/Distributed-Workflows.html

以上就是Git工作流模式及命令的使用讲解的详细内容，更多关于Git的工作流模式命令使用的资料请关注脚本之家其它相关文章！