git 行动指南

Git是一个分布式的版本管理工具。

在本地项目和服务器都会拥有版本库，本地版本库由自己控制，自由选择提交代码到服务器端

windows上也建议使用命令的方式来使用git，推荐使用客户端 ：http://msysgit.github.io/

git使用命令

信息配置

把开发者的信息配置到项目中，提交的时候就会附上开发者的这些信息。

git config --global user.name "whthomas"
git config --global user.email "whthomas93@gmail.com"

本地提交操作

使用commit命令可以将代码提交到本地版本库

git add .  #将所有改动文件添入缓存区
git commit -m "本次修改的注释（这个非常重要，是版本回退的重要信息,严禁随意填写！）"

分支操作

git branch #查看所有分支
git branch <name> #新建一个分支，一般不使用
git checkout master -b dev  #以当前master分支为基础，新建dev分支,并切换到dev分支上。一般使用这个命令新建分支。
git checkout dev #切换到dev分支上
git branch -d dev #删除dev分支，删除其他分支将dev换成需要被删除的那个分支名称就好了

git checkout origin/dev -b <name> #从服务器的分支上切出分支

合并操作

git checkout master
git merge --no-ff dev

先切换到master分支上，然后将dev合并到master分支上。

git的合并在默认情况下会采用fast-farward merge模式，将master直接指向dev分支上：

添加上 --no-ff选项之后，会执行正常合并，在Master分支上生成一个新节点，这样可以明确合并的操作：

在我们未来的开发之中，只有当功能开发完成并被大家确认之后，才能合并。

远程交互操作

我们在本地完成一系列的提交之后,需要把本地的代码库放到远端代码库供其他的小伙伴使用（这种方式很好地避免了经常性的代码冲突，我们在本地开发完成好了自己的功能并解决和远端服务器冲突之后才可以提交代码确保任何时候，远端服务器的代码都是干净的分支）。

git remote add <主机名> <网址> #添加远程主机，一般情况下主机名为origin
git push <远程主机名> <本地分支名>:<远程分支名> #推送本地分支上的内容到服务器上。
git pull <远程主机名> <远程分支名>:<本地分支名> #拉取远端服务器上的代码到本地使用。

提交策略

使用svn的时候，很多人习惯下班之前做一次提交，我们希望在迁移到git上之后，大家能将颗粒度减小。比如我们在开发一个新的模块的时候，每完成一个功能就做一次提交，在这个页面开发完成之后能做一次commit提交，这样一旦出现问题，回退的力度会小一些。

分支管理

分支是git一个非常重要的概念。

分支好比是在本地下载了多个完全相同的项目，然后再在这些目录上分别发开新功能，最后将不同的部分合并到一起，形成一个新的版本。

固定分支

我们约定开发中启用2个相对固定的分支：

• 主分支（master）：这个是主分支
• 开发分支（dev）：开发分支，这是我们主要维护的分支。

主分支

一个项目之中只保持一个master分支 , 所有提供给用户使用的正式版本，都在这个主分支上发布。

git的默认分支名字就叫master，它是自动建立的，在这条分支上的提交需要打上tag。表示发布的版本。

开发分支

日常开发应该在dev分支上完成，这个分支用来存放最新的版本。大家将开发完成的功能都合并到这个分支上。

如果版本形成稳定，那么dev分支就可以合并到master分支上发布了。

除了以上两个分支之外，我们还需要三种临时性的分支：

• 功能分支（feature）
• 预发布分支（release）
• 修补bug分支（fixbug）

这三个分支均属于临时性分支，在代码库中使用完成之后，应该被删除掉，使得代码库中总是只有dev和master两个分支。

功能分支

命名规则 feature-*

我们开发以功能为单位切换分支，如果在开发同一个功能，担心受他们开发的影响，也应当在当前功能分支上切换出新的分支，开发完成之后合并到原先的功能分支上。

git checkout -b feature-x develop #从develop新建feature分支

... #在feature分支一系列操作之后

git checkout develop #切换回develop分支
git merge --no-ff feature-x #合并feature分支到develop上

预发布分支

命名规则 release-*

预发布分支，合并到Master分支之前，我们可能需要有一个预发布的版本进行测试。

git checkout -b release-1.2 develop #从develop新建release-1.2分支

... #测到一些bug，一系列修复操作

git checkout master
git merge --no-ff release-1.2 

git tag -a 1.2 #对合并生成的新节点，做一个标签

#不要忘记了开发分支也需要解决bug后的版本
git checkout develop
git merge --no-ff release-1.2

修补bug分支

命名规则 fixbug-*

即使是正式版本发布之后bug仍然有可能存在。修复bug必须切换在新的分支上修复，在完成修复后再合并回master和dev分支。

特别注意在master分支上修复bug，bug修复完成之后也要记住将fixbug-*分支与dev做一次合并。

git checkout -b fixbug-0.1 master

git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1

git checkout develop
git merge --no-ff fixbug-0.1

git rebase操作

这个操作特别合适大家在功能分支开发中的合并。

我们经常会遇到合并冲突，这个时候，因为我们多人协作的时候，代码经常是同时开发，提交的commit不在一条时间线上。

假设我们在开发一个合同预览的功能，这条分支叫做feature-view-contract , 在本地和服务器上同时存在这条分支。

1. 新建一个分支，并且代码和服务器中代码同步

   git checkout origin/v2.0 -b temp

2. 为了保证新建的temp分支代码是最新的，可以多执行下面一步

git pull origin feature-view-contract:temp

3. 当你新建分支后，系统会自动checkout到temp分支上，此时

git checkout feature-view-contract

4. 合并代码，并整理

   git rebase temp //会将temp分支的代码合并过来，并按照提交的顺序排序

5. 因为顺序是重新整理的，所以肯定会出现冲突

6. 解决冲突，最后 git add . ，但不要 git commit

7. 解决后，执行 ：

   git rebase --continue

8. 重新提交代码： git push feature-view-contract

这个时候，所有的提交点都被整理到一条直线上，在服务器版本库上看起来就像一个人开发的一样。