使用git、git-flow与gitlab工作

liukun2009

　　本文转载自：蛋疼的axb

1.摘要
　　在工作中使用git代替svn也有一段时间了，对于git的一些特性/爱不释手的同时也一直遇到相同的问题：“这时候应该打什么命令？”。相对于svn或者vss的简单，git的学习成本还是有些高，如果要使用一个工具还要翻上300页的《Pro Git》，工具的使用成本甚至大于开发本身，这也是我写这篇文章的初衷。

2.安装
　　下载 git OSX 版
　　下载 git Windows 版
　　下载 git Linux 版
　　Linux下可以直接用apt-get install git或者yum安装

3.开始使用
　　注：这篇教程里所有git操作在命令行下执行，windows下可以右键-git bash打开命令行。
　　如果有人告诉你某某项目的git地址：
　　

git clone username@host:/path/to/repository　　

　　或者是你只想自己折腾一下,建立一个空白的版本库：
　　

git init　　


4.版本控制

4.1.本地版本库
　　要提交代码到git仓库需要两个命令：
　　

git add　　
git commit
-m “代码提交信息”　　

　　要撤销提交：
　　

git reset HEAD　　

　　要从从版本库恢复文件：
　　

git checkout —　　

　　在git文件夹中实际存在三个区域：
　　实际目录：实际修改的文件。
　　待提交区：暂存准备提交的内容，提交之后被清空。(也叫做index区）
　　已提交区：提交到本地git版本库的内容，有版本号。
　　对这三个区域的操作都可以在本地离线完成。
　　完整一些的状态图如下：
　　查看文件状态：
　　

git status　　

　　文件总共四种状态：
　　与git repository一致
　　与git repository不一致，已缓存
　　与git repository不一致，未缓存
　　还未添加到git repository

4.2.远程版本库
　　从远程更新：
　　

git pull　　

　　提交到远程：
　　

git push　　

　　远程git与本地git的关系大概是这样：

　　其中：remotes/origin是git用来管理远程版本库的的隐藏分支，一般不用理会。

5.分支与标记

5.1.分支
　　分支是用来将特性开发绝缘开来的。在你创建仓库的时候，master 是“默认的”。在其他分支上进行开发，完成后再将它们合并到主分支上。

　　创建一个叫feature_x的分支，并切换过去：
　　

git branch feature_x　　
git checkout feature_x
　　

　　切换回主分支：
　　

git checkout master　　

　　再把新建的分支删掉：
　　

git branch -d feature_x　　

　　除非你将分支推送到远端仓库，不然该分支就是 不为他人所见的：
　　

git push origin　　

　　如果要删除远端仓库里的某个分支：
　　

git push origin :　　


5.2.合并
　　要合并其他分支到你的当前分支（例如 master），执行：
　　

git merge　　

　　两种情况下，git 都会尝试去自动合并改动。不幸的是，自动合并并非次次都能成功，并可能导致 冲突（conflicts）。 这时候就需要你修改这些文件来人肉合并这些 冲突（conflicts） 了。改完之后，你需要执行如下命令以将它们标记为合并成功：
　　

git add　　

　　在合并改动之前，也可以使用如下命令查看：
　　

git diff<source_branch><target_branch>　　


5.3.标记
　　在软件发布时创建标签，是被推荐的。这是个旧有概念，在 SVN 中也有。可以执行如下命令以创建一个叫做 1.0.0的标签：
　　

git tag 1.0.0　　


6.工作流与规范化
　　在工作中，用一个分支来处理开发、测试、发布、线上hotfix等等流程是难以控制的：项目上线前你只想让其他人提交一个小修改，结果fetch下来的是另一个人为下次上线提交上来的几百个文件修改。
　　这里介绍利用git分支的特性避免这种情况的一种做法：

6.1.永久分支
　　首先，git远程版本库有两个永久分支，master与develop。
　　develop分支包含开发过程中最新的提交变更。有人会称之为“集成分支”。该分支是自动化每日构建的代码源。
　　当develop分支上的源码到达一个稳定的状态时，就可以发布版本。所有develop上的变更都应该以某种方式合并回master分支，并且使用发布版本号打上标签。
　　每次有变化被合并到master分支时，这就是一次新的产品版本发布。

6.2.临时分支
　　临时分支是开发或者发布过程中被创建、一段时间后再删掉的分支，同一时间内可能会有多个临时分支在并行工作。

6.2.1.feature
　　作用：开发新的功能
　　分支来源：develop
　　分支结束时合并到：develop
　　特 性分支（有时也被称作topic分支）是用来为下一发布版本开发新特性。当开始开发一个特性的时候，该特性会成为哪个发布版本的一部分，往往还不知道。特 性分支的重点是，只要特性还在开发，该分支就会一直存在，不过它最终会被合并回develop分支（将该特性加入到发布版本中），或者被丢弃（如果试验的 结果令人失望）。
　　特性分支往往只存在于开发者的本地仓库中。

6.2.2.release
　　作用：准备发布新版本
　　可能的分支来源：develop
　　分支结束时合并到：develop和master
　　发布分支为准备新的产品版本发布做支持。它允许你在最后时刻检查所有的细节。此外，它还允许你修复小bug以及准备版本发布的元数据（例如版本号，构建日期等等）。在发布分支做这些事情之后，develop分支就会显得比较干净，也方便为下一大版本发布接受特性。
　　从 develop分支创建发布分支的时间通常是develop分支（差不多）能反映新版本所期望状态的时候。至少说，这是时候版本发布所计划的特性都已经合 并回了develop分支。而未来其它版本发布计划的特性则不应该合并，它们必须等到当前的版本分支创建好之后才能合并。
　　正是在发布分支创建的时候，对应的版本发布才获得一个版本号——不能更早。在该时刻之前，develop分支反映的是“下一版本”的相关变更，但不知道这“下一版本”到底会成为0.3还是1.0，直到发布分支被创建。版本号是在发布分支创建时，基于项目版本号规则确定的。

6.2.3.hotfix
　　作用：修复发行版bug
　　分支来源：master
　　分支结束时合并到：develop和master
　　热 补丁分支和发布分支十分类似，它的目的也是发布一个新的产品版本，尽管是不在计划中的版本发布。当产品版本发现未预期的问题的时候，就需要理解着手处理， 这个时候就要用到热补丁分支。当产品版本的重大bug需要立即解决的时候，我们从对应版本的标签创建出一个热补丁分支。
　　使用热补丁分支的主要作用是（develop分支上的）团队成员可以继续工作，而另外的人可以在热补丁分支上进行快速的产品bug修复。

6.2.4.流程图

6.3.gitlab与code review
　　在了解如何review之前先明确几个观点：
　　1、master分支中的任何版本都认为是可以立即部署的
　　2、每一次master分支的变更都来自于其它分支向master的合并操作。
　　3、对master的修改需要review。
　　借助于gitlab的merge request机制，与上面说的工作流程，我们可以在release分支正式合并到master分支之前建立merge request，在其他人review完成这次合并之后再正式进行合并。

6.3.1.如何review
　　1、将需要合并到master的分支push到gitlab。
　　2、进入工程-merge request -create new merge request
　　3、选择源分支、目标分支，确定。
　　4、review负责人进入merge request，确认没有问题之后选择Auto Merge（或者手动在本地合并之后再push到gitlab），并关闭这个merge request，完成。
　　5、如果发现问题那么在有问题的行下注释，并提醒request的发起人及时修改。

6.4.git flow
　　git flow是git的辅助工具，实质上是一些分支-合并的脚本集合，使用git flow可以更轻松的完成对各种特性分支的操作。
　　安装：
　　

apt-get install git-flow　　

　　将git库转换为git-flow库：
　　

git flow init　　

　　实质上这一步只是为git flow中的几个特性分支命名。
　　开始一个新功能：
　　

git flow feature start xxxx　　

　　提交这个功能到远程库：
　　

git flow feature publish xxxx　　

　　完成功能，合并到develop：
　　

git flow feature finish xxxx　　

　　记得删除远程仓库里的分支：
　　

git push origin :xxxx　　

　　release,hotfix与之类似，唯一的一点区别：hotfix目前没有publish功能，所以提交远程仓库的这一步要改成：
　　

git push origin hotfix/xxxx:hotfix/xxxx　　

　　注意：
　　git flow只是在本地执行分支/合并操作的脚本，不是一个流程管理工具。

7.更进一步
　　几个常用命令：
　　git reset
　　A). –hard：重设（reset） index和working directory，自从以来在working directory中的任何改变都被丢弃，并把HEAD指向。
　　B). –soft：index和working directory中的内容不作任何改变，仅仅把HEAD指向。这个模式的效果是，执行完毕后，自 从以来的所有改变都会显示在git status的”Changes to be committed”中。
　　C). –mixed：仅reset index，但是不reset working directory。这个模式是默认模式，即当不显示告知git reset模式时，会使用mixed模式。
　　**git checkout **
　　-b 签出并创建分支
　　-t 签出并追踪远程分支
　　**git rebase **
　　合并/修改提交
　　

git remote -av　　

　　显示所有远程仓库
　　

git push -u　　

　　设置分支对应的远程仓库

8.参考资料

• git-the simple guide
  
• 《Pro Git》
  
• A successful git branching model
  
• Github-flow