在实际项目开发中，往往都是多人配合开发一个项目，甚至多人配合开发一个功能或模块，这就要考验项目经理的管理和成员的默契配合了。

如何控制版本不冲突，代码不冲突，冲突了如何解决等问题，这些问题都是开发者必须要掌握的知识。下面针对这几个问题进行实践。

分支

为什么要有分支？

分支就是为了隔离和验证新功能、修复或实验性代码的独立开发线路，目的是在不影响主分支（master）稳定性的前提下，安全地进行各种测试和迭代。

主分支

主分支（MASTER）一个项目只有一个，主分支是原始的稳定的核心版本，是所有分支的父级，主分支往往都是生产发布的代码，因此这个版本不轻易改动，只有需要发布的代码才被合到主分支上。GIT在开始创建仓库后，就只有一个master分支。可以查本地仓库和远程仓库的所有分支：

git branch -a

上图，绿色的是本地分支，红色的是远程分支，项目刚刚创建，本地和远程都只有一个master分支，一般是一一对应的。

测试分支

在项目中，测试分支是不可缺少的一个分支，测试分支可以包括所有已上线，在开发，在测试等全部功能的代码，也可以是专门测试一个版本的代码，测试分支是增量的方式不断被开发成员合并过来，是提供给测试人员检查的版本。一般情况下，项目只有一个测试分支，不过不代表所有项目都这样，大型项目对分支比较细一点。

在实际应用中，开发成员A和成员B同时配合开发同一个功能，他们开发需要测试的代码都会合并到测试分支（TEST），也就是测试分支是专门发布到测试环境的代码，用于测试。测试通过后回到下一个环境，预生产发布。

预生产分支

测试通过的版本还有可能会有预生产版本（PRE），除此之外，其他的分支基本上都算是开发分支和其他版本了。

我个人对GIT的使用

在开发中，我并没有使用编辑器的GIT插件工具去使用GIT，我比较习惯通过命令去使用GIT。下面谈谈个人使用的过程以及感受。

创建新分支

需求来了，我往往都是开辟一个分支，也就是说，我们项目组目前是以某些需求作为开分支的直接原因，也就是需求和分支是一对一的。

之后上线的话，项目经理就会去合并这个分支，不和其他需求有混淆，当然我也想知道你们是怎么做的，可以下面留言。

下面演示一下，创建TEST分支的流程

1）切换到主分支（MASTER）

git checkout master

为什么是主分支，因为主分支是已经上线的分支，我们写的代码之后是不是也需要上线，所以将主分支作为基础分支去创建分支。

2）在某个分支（master）的基础上，创建本地分支test

git checkout -b test

此时，本地分支test就是主分支master的一个副本，代码完全一样。本地分支有了，远程分支没有呢，我们需要推送过去。

可以查一下所有分支

git branch -a

3）把本地分支test推送到远程

git push [远程仓库名] [本地分支名]:[远程分支名]

如果你不知道远程仓库名称，就查一下

git remote

或

git remote -v

有些项目，还有upstream名称，这是上游仓库名称，如果你的创建是直接 git init的就不会有upstream名称，一个仓库还有两个地址 fetch和push，这是因为git将上传和拉取分开，这是git的管理方式。

简单点的命令推送远程

git push origin test

我为什么不这么写：git push origin test:test，因为test和test同名，所以可以省略，一般情况下，远程和本地都是同名的，不同名也行，但是很麻烦，不方便。

执行完后，查看所有分支，都有了哦！

4）拉取代码

本地分支和远程分支都有了，而且同名，那我们拉取代码

git pull origin test

这个命令的全部格式：

git pull [远程仓库名] [远程分支名]:[本地分支名]

注：原因是本地和远程同名，同名，命令可以简化：git pull origin test

为了再简化命令，我们不如直接配置当前test的对应远程分支：

git branch --set-upstream-to=origin/test test

这样，拉取代码，就可以简化成：git pull，同意上传代码也是git push。

在啰嗦一点，git pull实际是两个步骤的合并：是git fetch和git merge的合体。

git fetch：从远程仓库下载最新提交
git merge：将下载的提交合并到当前本地分支

所以使用git pull会有冲突，没办法，多人开发有冲突是不可避免的。那么就解决冲突呗。

我一般都是使用BCompare对比工具手工解决。

5）上传您的代码

git push 上传你的代码，有冲突就先解决冲突，再上传。

git push

之后的日常

以上搞完后，之后的日常就是写代码，提交代码，上传代码。写代码之前，先拉取一下代码，这样能减少冲突。

合代码

这一步也要掌握，不能少，当你的分支上的代码开发完了，需要合拼到某某分支，最简单的还是 BCompare工具去合并代码。

关于合并代码，我的日常是：比如我的开发分支是 a1，我刚刚修改了一个功能，然后提交并且上传了，我会使用命令查看提交的哈希码

git reflog

我用这个码，就可以合并到test分支，给测试人员进行测试了。先切换到test

git checkout test

在合并过去，

git cherry-pick d5b9ce8

git cherry-pick 是Git中用于将特定提交应用到其他分支的强大工具。它允许你从一个分支 “复制” 一个或多个提交，并在另一个分支上重新应用，而不必合并整个分支，合并整个分支会让你崩溃。

合并后，查看状态有没有冲突

git status

这个命令可以让你知道当前有没有更新，有没有冲突等，这个命令太好用了，会有提示你如何操作。

当然，以上只是个人的方式，也会有更好的方式，我没去学。 关于代码最耗时间的还是处理冲突吧。