git使用方法简明教程 - 团队篇

简述

首先,如果你没有看过前文。我推荐你先看一下我的上一篇文章git使用方法简明教程 - 个人篇,这样你能对git这个程序员必用的软件能够有一定的了解。

工作流

团队使用代码进行协作编程与个人使用不太一样。因为它一般来说是在多个分支上进行操作。这里涉及到一个分支(branch的概念,我稍后再讲)

一般来说一个团队的代码仓库至少会有2个以上的分支。有一个生产环境的master (或者release) 分支,一个用于内部内部开发的dev分支。
有两种模式,一种是小团队的快速开发。多个人在同一个分支开发。通过不断地进行push和pull进行代码间的同步。另一种是以开发分支为基础。每个人分出一个自己的分支,完成开发后合并到主开发分支。这种情况可以根据实际需求选择一个人一个个人分支或者一个人开发一个任务就分出一个分支两种情况。

分支

分支,英文名branch。可以通过git branch命令查看本地的分支。
使用git checkout [分支名]的方式来切换不同分支。
我们在使用git log命令查看提交简述的时候也能看到分支所在位置。

分支分为本地分支和远程分支。远程分支是远程代码仓库在本地的映射。我们可以通过git fetch命令进行同步本地的远程分支。通过git branch -r命令可以查看所有的远程分支。
我们正常操作都是操作的本地分支。

通过git checkout -b [新分支名]就可以从当前位置创建一个新的分支。并且切换到新的分支上来。
在完成代码编辑的时候我们可以通过git merge命令进行分支的合并操作。
举例:
我有两个分支masterdev.分别是主分支和开发分支。我在开发分支上完成了一些代码的提交后。想要把dev分支的变更合并到主分支

1
2
$ git checkout master
$ git merge dev

如果有代码冲突的情况我们需要解决冲突,然后使用git commit命令提交合并
如果在代码冲突的过程中想要中断代码合并的过程,使用git merge --abort命令

代码冲突

代码冲突是多人协作时常见的问题,因为你没法保证在你进行编辑的时候其他的不会对代码进行修改。在大多数情况下git会自动处理代码变更。但如果两个开发者共同修改了同一处代码时。git无法自动处理。那么就需要开发者手动解决冲突。
当git出现无法处理的冲突时,它会告知你冲突的文件,并修改文件共同修改处的代码变更为:

1
2
3
4
5
<<<<<<<head
这里是当前代码
=======
这里是远程代码
>>>>>>>xxxxxxxxxx(发生冲突的hash值)

当出现这种情况时,作为开发者你需要做的是仔细比较两边的代码,并把多余的东西删除。然后把所有的冲突全部解决完毕后,提交代码。

rebase

NOTE:rebase是一种破坏性的行为, 请尽量不要在公共分支上进行操作

当我们在自己的分支提交了一系列代码后,需要把完成的功能提交到公共开发分支,那么我们要做的第一步是先把公共分支的代码同步到我们自己的分支。简单的,我们当然可以使用git merge命令。但是,这样会留下一个git生成的merge commit点,而这个commit是无意义的。对于code review(代码审查)来说是一个比较影响的东西。当然了,merge commit 点的好处是所有的操作都是线性的。在进行合并个人分支到公共分支的过程中最好使用merge,而把公共分支同步到个人分支的时候,我建议使用git rebase, 他能让你看上去是从当前公共分支创建出来的个人分支进行往前编辑
rebase的原理是把往前一段距离的代码提交重新打开,然后重新提交一遍。因为是一种破坏性的行为,因此无法与远程服务器同步,需要使用git push -f命令强制覆盖远程分支。

举例:
我有一个个人开发的分支moonrailgun, 然后有一个开发分支dev。在经过一段时间的开发后,两个分支各向前跑了几个commit。现在我希望能够把我的moonrailgun合并到dev分支。为了保证冲突能现在我的个人分支解决,我需要先把dev的变更同步到moonrailgun分支

1
2
# 当前在moonrailgun分支
$ git rebase dev

如果出现冲突。需要解决冲突,然后git add以后使用git rebase --continue命令继续操作。
如果想要中断rebase的过程,使用git rebase --abort

然后你就能很方便的把moonrailgun分支合并到dev分支上了,并且代码的历史线会很干净。

P.S.: 如果团队在分支上进行代码操作,那么常常会出现代码不同步的问题。那么为了保证代码分支线的干净。最好不要使用git pull命令(因为这会留下一个合并的commit点)。推荐的操作如下:

1
2
3
4
$ git fetch
$ git log origin/master
# 查看最新的远程commit的hash值。复制下来
$ git rebase <hash>

这样可以完美的处理单分支多用户进行代码提交。

应用patch和使用patch

patch是一种线下通过文件传输同步变更的方式

基于历史原因, git有两套使用patch的方式

旧的:

1
2
3
git diff > 1.patch # 生成patch
git apply --check 1.patch # 检查patch是否可用,如果没有任何输出说明可以正常使用
git apply 1.patch # 应用patch

新的:

1
2
git format-patch HEAD^ # 等价于git format-patch -1
git am <patch file>

在一般情况下推荐使用新的方式,基于commit来控制。但是如果出现特殊情况,比如未提交的代码想要交换的话,可以考虑使用旧的patch方式。

这也是为什么git没有把旧方式移除的原因

文章目录
  1. 1. 简述
  2. 2. 工作流
  3. 3. 分支
  4. 4. 代码冲突
  5. 5. rebase
  6. 6. 应用patch和使用patch