Git基本命令和GitFlow工做流

本篇博客讲解了git的一些基本的团队协做命令，和GitFlow工做流指南

git 团队协做的一些命令

• 1.开分支

git branch 新分支名
例如，在master分支下，新开一个开发分支：
git branch dev

• 2.切换到新分支

git checkout 分支名
例如，在master分支下，切换到新开的dev：
git checkout dev

• 3.开分支和切换分支合并到一个命令

git checkout -b 新分支名
例如，新开一个开发分支，并当即切换到该分支：
git checkout -b dev

• 4.切换回原分支

git checkout 原分支名
例如，切换回master
git checkout master
注意：当前分支有修改，还未commit的时候，会切换失败，应当先commit，但能够不用push

• 5.合并分支

git merge 须要合并的分支名
例如，刚刚已经切换回master，如今须要合并dev的内容：
git merge dev
建议在GitLab(或者其余git系统)上面建立merge request的形式来进行分支的合并和代码审核。

• 6.查看本地分支列表

git branch -a
前面带remotes/origin 的，是远程分支

• 7.查看远程分支列表

git branch -r

• 8.向远程提交本地新开的分支

git push origin 新分支名
例如，刚刚在master下新开的dev分支：
git push origin dev

• 9.删除远程分支

git push origin :远程分支名
例如，删除刚刚提交到远程的dev分支：
git push origin :dev

• 10.删除本地分支

git branch 分支名称 -d
例如，在master分支下，删除新开的dev分支：
git branch dev -d
注意：若是dev的更改，push到远程，在GitLab(或者其余git系统)上面进行了merge操做，可是本地master没有pull最新的代码，会删除不成功，能够先git pull origin master，或者强制删除
git branch dev -D

• 11.更新分支列表信息

git fetch -p

• 12.TortoiseGit(乌龟git)

  不能否认，在windows下，这个是个不错的工具。无论你是命令行新手仍是重度使用者，我以为均可以尝试一下。

Git工做流指南：Gitflow工做流

在你开始阅读以前，请记住：流程应被视做为指导方针，而非“铁律”。咱们只是想告诉你可能的作法。所以，若是有必要的话，你能够组合使用不一样的流程

Gitflow工做流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工做流复杂几分，但提供了用于一个健壮的用于管理大型项目的框架。

Gitflow工做流没有用超出功能分支工做流的概念和命令，而是为不一样的分支分配一个很明确的角色，并定义分支之间如何和何时进行交互。除了使用功能分支，在作准备、维护和记录发布也使用各自的分支。固然你能够用上功能分支工做流全部的好处：Pull Requests、隔离实验性开发和更高效的协做。

工做方式

Gitflow工做流仍然用中央仓库做为全部开发者的交互中心。和其它的工做流同样，开发者在本地工做并push分支到要中央仓库中。

历史分支

相对使用仅有的一个master分支，Gitflow工做流使用2个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支做为功能的集成分支。这样也方便master分支上的全部提交分配一个版本号。

剩下要说明的问题围绕着这2个分支的区别展开。

功能分支

每一个新功能位于一个本身的分支，这样能够push到中央仓库以备份和协做。但功能分支不是从master分支上拉出新分支，而是使用develop分支做为父分支。当新功能完成时，合并回develop分支。新功能提交应该从不直接与master分支交互。

注意，从各类含义和目的上来看，功能分支加上develop分支就是功能分支工做流的用法。但Gitflow工做流没有在这里止步。

发布分支

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

使用一个用于发布准备的专门分支，使得一个团队能够在完善当前的发布版本的同时，另外一个团队能够继续开发下个版本的功能。
这也打造定义良好的开发阶段（好比，能够很轻松地说，『这周咱们要作准备发布版本4.0』，而且在仓库的目录结构中能够实际看到）。

经常使用的分支约定：

用于新建发布分支的分支: develop

用于合并的分支: master

分支命名: release-* 或 release/*

维护分支

维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是惟一能够直接从master分支fork出来的分支。修复完成，修改应该立刻合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。

为Bug修复使用专门分支，让团队能够处理掉问题而不用打断其它工做或是等待下一个发布循环。你能够把维护分支想成是一个直接在master分支上处理的临时发布。

示例

下面的示例演示本工做流如何用于管理单个发布循环。假设你已经建立了一个中央仓库。

建立开发分支

第一步为master分支配套一个develop分支。简单来作能够本地建立一个空的develop分支，push到服务器上：

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

如今每一个开发都有了这些历史分支的本地拷贝。

工程师A和工程师B开始开发新功能

这个示例中，工程师A和工程师B开始各自的功能开发。他们须要为各自的功能建立相应的分支。新分支不是基于master分支，而是应该基于develop分支：

git checkout -b some-feature develop

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

git status
git add
git commit

工程师A完成功能开发

添加了提交后，工程师A以为她的功能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分支。冲突解决方法和集中式工做流同样。

工程师A开始准备发布

这个时候工程师B正在实现他的功能，工程师A开始准备她的第一个项目正式发布。像功能开发同样，她用一个新的分支来作发布准备。这一步也肯定了发布的版本号：

git checkout -b release-0.1 develop

这个分支是清理发布、执行全部测试、更新文档和其它为下个发布作准备操做的地方，像是一个专门用于改善发布的功能分支。

只要工程师A建立这个分支并push到中央仓库，这个发布就是功能冻结的。任何不在develop分支中的新功能都推到下个发布循环中。

工程师A完成发布

一旦准备好了对外发布，工程师A合并修改到master分支和develop分支上，删除发布分支。合并回develop分支很重要，由于在发布分支中已经提交的更新须要在后面的新功能中也要是可用的。另外，若是工程师A的团队要求Code Review，这是一个发起Pull Request的理想时机。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

发布分支是做为功能开发（develop分支）和对外发布（master分支）间的缓冲。只要有合并到master分支，就应该打好Tag以方便跟踪。

git tag -a 0.1 -m "Initial public release" master
git push --tags

Git有提供各类勾子（hook），即仓库有事件发生时触发执行的脚本。能够配置一个勾子，在你push中央仓库的master分支时，自动构建好对外发布。

最终用户发现Bug

对外发布后，工程师A回去和工程师B一块儿作下个发布的新功能开发，直到有最终用户开了一个Ticket抱怨当前版本的一个Bug。为了处理Bug，工程师A（或工程师B）从master分支上拉出了一个维护分支，提交修改以解决问题，而后直接合并回master分支：

git checkout -b issue-#001 master

Fix the bug

git checkout master
git merge issue-#001
git push

就像发布分支，维护分支中新加这些重要修改须要包含到develop分支中，因此工程师A要执行一个合并操做。而后就能够安全地删除这个分支了：

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

最后

Git是一个不错的版本管理工具，但也仅仅是工具。记住，这里演示的工做流只是可能用法的例子，而不是在实际工做中使用Git不可违逆的条例。因此不要畏惧按本身须要对工做流的用法作取舍。不变的目标就是让Git为你所用。

参考资料

1. Comparing Workflows https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/
2. Git 版本控制系統 http://ihower.tw/git/index.html