乐趣区

关于git:Git入门二团队开发基本流程概述

jiezi

前言

本文旨在帮忙没有接触过 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 分支产生影响。

接下来就开始写代码了。

步骤二、提交代码

假如当初我的代码曾经写完了，在齐全保留之后，终端中的分支号是黄色的，黄色示意代码有改变，但尚未提交。

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

// 查看代码状态
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

而后，本地的工作分支，就和近程仓库的主分支截然不同了，从新编写代码即可。

总结 一图胜千言

团队合作开发的泳道图大略是这样的：

成员在支付工作时，是一起进行的，谁也不晓得哪个成员先提交代码。就像异步申请一样，谁也不晓得哪个申请先返回。

因而，要想顺利的实现单干，有两个要害：

  • 一是具备解决抵触的能力，
  • 二是及时的拉取近程仓库的代码变更。

版权申明

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

退出移动版