Git入门（二）——团队开发基本流程概述

前言

本文旨在帮助没有接触过Git的同窗，使用Git以及GitHub的基本功能，适用于初学者。

因为内容比较多，一次写不完，故作成连载，之后还会更新其它内容。

第一期：Git入门（一）——基本操做及理论
第二期：Git入门（二）——团队开发基本流程概述 (本期)

步骤零：把项目跑起来

分为如下两种状况：全新的项目，中途接手的项目

不管哪一种状况，都应该先把GitHub仓库clone到本地，有一个区别就是，全新的项目须要先在GitHub上新建仓库。

//做用：把地址中的在线仓库clone到本地的文件夹中
git clone <仓库地址> <本地的文件夹>

请耐心等它跑完。
在本地拥有了代码以后，就开始跑项目了。

若是是已有的旧项目，接下来就是检查开发环境、数据库、Nginx、redis等等，以确保项目能成功的跑起来。
若是是新项目，仓库中只有一个readme.md，就不须要这一步（但须要额外的一步项目初始化，具体如何初始化，取决于开发使用的编程语言）。

步骤一：把本地仓库调整到工做状态

出于安全起见，一个严谨的团队，必然会制定一些合做开发的规范，好比

• 不能向主分支直接提交代码
• 不能由旧分支向新分支发起合并请求

所以，在领取一个任务时，咱们本地的仓库可能刚刚完成上一个任务，所以须要进行切回主分支、同步远程仓库的代码、创建新分支等等操做。

假设咱们领取了新任务，issue的编号是300，而咱们本地仓库还处于上次的275分支上，而且刚刚提交完代码：

这时候须要先切换回主分支：

// 切换到主分支
git checkout master

而后把远程主分支同步到本地主分支：
(分支关系： origin/master -> master)

// 拉取远程仓库的代码
git pull

执行上一步之后，咱们本地的代码已经和远程仓库彻底一致了。
接下来为新领取的任务建立一个分支：

// 建立新分支
git checkout -b <分支号>

// 示例：建立分支编号为300的新分支
git checkout -b 300

到此为止，咱们既更新了本地的代码为最新版本，又为新领取的任务作好了准备，由于新的issue将在300分支上完成开发，所以，在合并代码以前，不会对master分支产生影响。

接下来就开始写代码了。

步骤2、提交代码

假设如今个人代码已经写完了，在彻底保存以后，终端中的分支号是黄色的，黄色表示代码有改动，但还没有提交。

咱们能够查看代码变动信息（这一步不是必须的）：

// 查看代码状态
git status

从返回的结果来看，有一个文件是modified状态，这说明：
Git发现了一个文件出现更改，但并没有记录这个更改，所以提示信息是红色的。

那么咱们怎么让Git记录这些更改呢？

// 记录当前目前的全部文件变动
// 此命令应该在项目根目录执行
git add .

再git status 就能够看到刚刚显示红色的文件已经变成绿色：

接下来能够提交代码了（也至关于打一个保存点）：

// 在本地提交代码变动，最后是备注信息
git commit -m <备注信息>
// 示例
git commit -m issue300已完成

提交完成后，本来黄色的分支号会从新变成绿色：

接下来就是把本地的代码提交到远程分支上：
(分支关系 300 -> origin/300)

// 把本地的分支推送到远程仓库
git push origin <分支号>

// 示例：把本地的300分支推送到远程的300分支
git push origin 300

在提示信息中，能够看到，但愿用户访问GitHub来创建Pull Request。
至于GitHub的操做步骤，在第一期中已经讲解，本文专一于讲解Git命令。

附录一 解决冲突

冲突产生缘由

只要有代码合并就不可避免的产生冲突，冲突的产生，仍是要从分支提及。

刚刚咱们提到了一条规范：

• 不能向主分支直接提交代码

基于这个规范，团队的成员们须要分别在本身的分支上编写，最终依次向主分支发起合并。

在提交代码时，Git会以“行”为单位，记录每一行代码的改动状况，好比，在test分支，把某一行的123改为了456，Git会记录下:
123 -> 456
合并代码时，Git会找到master分支上的123这一行，而且改为456:
123 -> 456

咱们先看一种状况：

若是A把123改为了456，B更新了A修改以后的代码，又把它改为了789，

此时是不会有冲突的，由于B是把456改为了789，而不是把123改为了789。

但下面这种状况就不同了：

A把123改为了456，而且合并到主分支，但B没有更新A的更改，而是直接把123改为了789，那么，再去合并B的分支时，就会显示冲突

那么Git到底该听谁的？

所以就须要解决冲突了。
这也就是为何有了第二个规范：

• 不能由旧分支向新分支发起合并请求

在合并代码时，当前的改动必须基于最新的主分支

解决冲突

发生冲突时有两种解决办法，一是在线上修改，二是将冲突代码拉下来，在本地修改。

若是冲突发生在本地，合并代码时会提示conflicts，而且会提示具体哪一个文件发生冲突：

示例中是test.txt文件发生冲突，因此打开文件：

会出现一排<<<<<<<和一排>>>>>>>，中间夹住的，就是冲突的代码。

图中，当前的代码是789，而300分支的成员想改为456。
解决办法：

• 将冲突的代码删掉一部分，使程序能够正常运行（好比，在示例中，我打算删掉789）
• 删掉全部的箭头、＝等等
• 未发生冲突的代码不动
• 保存文件
• 从新执行git add .
• 从新执行git commit -m <备注信息>，把合并的结果提交

最终的效果以下：

代码只剩一行“456”，终端中从新显示绿色提示符。

附录二 更新代码

刚才说到第二条规范：

• 不能由旧分支向新分支发起合并请求

好比，当你还在写本身的issue时，其余成员已经成功的向主分支贡献了代码。此时，主分支发生更新，而你的分支仍是基于旧的主分支，所以你须要把新的主分支拉取下来。

这个时候，若是直接用git pull，大几率会出问题。

因此须要用到下面的方案：

// 把远程仓库的全部变动同步到本地的origin镜像中
git fetch --all

此时未进行代码合并，因此本地的代码没有变化。

// 把主分支合并到当前工做的分支
git merge origin/master

此时，你当前的工做分支再也不基于旧的主分支，因为合并，已经基于新的主分支了。
在合并过程当中也可能出现冲突，按照附录一的方法解决便可。

附录三 重置代码

若是你的代码出现了严重错误，想放弃所有更改，重置为最新版本的主分支代码，能够在当前的工做分支上执行：

// 拉取远程仓库的全部更改
git fetch --all
// 把当前工做分支的代码，用最新的master分支彻底替换
git reset origin/master

而后，本地的工做分支，就和远程仓库的主分支如出一辙了，从新编写代码便可。

总结 一图胜千言

团队合做开发的泳道图大概是这样的：

成员在领取任务时，是一块儿进行的，谁也不知道哪一个成员先提交代码。就像异步请求同样，谁也不知道哪一个请求先返回。

所以，要想顺利的完成合做，有两个关键：

• 一是具有解决冲突的能力，
• 二是及时的拉取远程仓库的代码变动。

版权声明

本文做者： 河北工业大学梦云智开发团队 - 刘宇轩