> 我们研发开源了一款基于 Git 进行技术实战教程写作的工具，我们图雀社区的所有教程都是用这款工具写作而成，欢迎 [Star](https://github.com/tuture-dev/tuture) 哦 > 如果你想快速了解如何使用，欢迎阅读我们的 [教程文档哦](https://www.yuque.com/tuture/product-manuals/wsv091) 在大多数工作中，我们都将使用 Git 作为团队协作开发的工具。 **本文总结了图雀团队协作开发的流程与规范，仅供参考。最优的解决方案还是需要结合团队的实际情况，具体问题具体分析。** 为了让大家能够非常清晰直观地了解协作开发的流程，大家在看的时候可以打开 Learn Git Branching 的[沙箱运行环境](https://learngitbranching.js.org/?NODEMO)来实践（可以直接输入提供的代码）。在左边的终端中输入命令，就会在右边看到相应的动画。其中左边的实线圆圈代表本地仓库，右边的虚线圆圈代表远程仓库，`*` 号指向的是当前分支，`o/master` 就是远程分支（ `o` 就相当于 `origin` ）。 ![](https://cdn.learnku.com/uploads/images/202005/13/28209/gyA2XST6yf.png!large) **由于 Learn Git Branching 为了演示和学习的方便对部分命令做了简化，我将指出在实际操作中应当输入的命令。** ## 基本流程接下来将重点讲述以下两个流程： - 贡献代码 - 更新本地仓库 ### 贡献代码接下来的流程描述了在接到开发任务后，如何为中心仓库贡献代码。 #### 将仓库 clone 到本地 ```bash $ git clone ``` > 实际命令应当提供 URI 参数，例如： > > ```bash > $ git clone https://github.com/dhucst/cooperation.git > ``` #### 开启新分支 ```bash $ git checkout -b B1 ``` 为了便于演示，我们将新分支命名为 `B1`。在实际开发中，新分支的命名应当遵循以下原则： - 使用 kebab-case，例如 `new-branch` ，而不是 `new_branch` 或 `newBranch` - 尽量能概括这个分支所要完成的任务 - 如果是为了解决某个 Issue，在最后加上 Issue 的编号，例如 `fix-75` #### 编写代码并提交 ```bash $ git commit ``` > 实际命令应当要先执行 `git add` 来将修改的文件添加到暂存区，例如： > > ```bash > $ git add . > $ git commit > ``` Commit Message (Log) 的书写是有比较严格的规范的，会在后文的 **提交信息书写规范** 中详细阐述。 ##### 推送分支 ```bash $ git push ``` > 实际命令在**第一次** push 任何分支时，应当指定 remote 和分支名称： > > ```bash > $ git push origin B1 > ``` 有时候我们的分支会在一夜之间“过时”。什么是过时的分支，我们该怎样处理？不要方，后面会讲到。 #### 提交 Pull Request > 这一步骤无需在 Learn Git Branching 中操作。将分支提交到远程仓库后，打开仓库的 GitHub 页面，应该会看到下面这样黄色的提示框： ![image-20200429091859922](https://cdn.learnku.com/uploads/images/202005/13/28209/NrMcD8uSbB.jpeg!large) 然后点击 Compare & pull request 按钮，即可进入到提交 Pull Request 页面。 ![](https://cdn.learnku.com/uploads/images/202005/13/28209/HFWwnBkgg9.png!large) 填写 Pull Request 标题所遵循的原则与 Commit message 大致相似。在填写 Pull Request 的详细内容时，如果是为了解决某个或多个 Issue 时，可以使用 `Close(s)`, `Fix(es)` 或 `Resolve(s)` 关键词来关闭某个 Issue，例如 `Fix #75` 。点击 Create pull request 按钮后，即可完成本次 PR。如果经讨论后发现需要修改，则在本地仓库修改后直接 `git push` 继续提交即可。如果代码通过了评审，则会由项目管理者将此分支并入 master 中，本次贡献代码流程结束。 ### 更新本地仓库接下来的流程介绍了当团队其他成员贡献代码后，如何将远程仓库的更新同步到本地。如果你在使用 Learn Git Branching 边看边练，请输入以下命令： ```bash $ reset $ git clone ``` #### 其他成员贡献代码 ```bash $ git fakeTeamwork 2 ``` > 实际没有这条 Git 命令 😂，是 Learn Git Branching 提供用于练习协作的。这时候你会发现远程的仓库有了本地没有的提交 `C2` 和 `C3` 。 #### 拉取远程代码我们先来看第一种比较简单的情况： ![](https://cdn.learnku.com/uploads/images/202005/13/28209/w4awsFbi8n.png!large) 这时候一眼就可以看出，只需把远程的 `C2` 和 `C3` 直接拉取过来接在本地的 `C1` 后面就可以了： ```bash $ git pull ``` 接着我们来看另一种比较棘手的情况： ![](https://cdn.learnku.com/uploads/images/202005/13/28209/5UYgjl4llu.png!large) 需要输入的命令如下： ```bash $ reset $ git clone $ git checkout -b B2 $ git commit $ git fakeTeamwork 2 ``` 对着图看，我们在 `B2` 分支上在开发某个新功能，这时候远程仓库已经更新到了 `C4`，很显然我们本地的 master 分支和 `B2` 分支都不是最新的了。这种情况很常见：几个小伙伴从同一个起点（在这里就是 `C1` ）各自开发新功能时，其他人先于我们提交。大多数情况下，请遵循这一条原则：**只更新 master 分支。** > 这一原则对于并行开发并不适用，我们会在本知识库后续文档中讲解。 ```bash $ git checkout master $ git pull ``` ![](https://cdn.learnku.com/uploads/images/202005/13/28209/Yig2fQCLvt.png!large) 这时候，我们就会认为 `B2` 分支已经**过时**（outdated），因为它没有最新的 `C3` 和 `C4` 。但过时的分支并不意味着没有价值了，我们可以像前面所讲解的那样 push 到远程仓库： ```bash $ git checkout B2 $ git push ``` 然后一样可以发起 Pull Request。GitHub 会提示你这条分支已经过时，你可以点击 Update Branch 按钮来更新这一条分支（通常由项目管理者来执行这一操作）。 ### 小结团队协作开发的模型只涉及两个核心流程：贡献代码和更新本地仓库。 ![](https://cdn.learnku.com/uploads/images/202005/13/28209/zpoSCgreZC.png!large) 贡献代码的流程： ```bash $ git clone $ git checkout -b new-branch $ git add . $ git commit $ git push origin new-branch ``` 更新代码库的流程： ```bash $ git checkout master $ git pull ``` ## 并行开发一个项目的开发往往由多个开发任务组成，每个人都会负责承担一个或多个开发任务。最简单、最理想的情况当然是：同学 A 开始贡献代码，成功合并后所有人更新本地代码库；接着同学 B 开始贡献代码，合并后所有人更新本地代码库；然后是同学 C、D、E…… 不会有任何冲突，只需用到前面 **基本流程** 所介绍到的命令，多么轻松愉快！唯一的问题就是：这样的开发显然进度很慢，而且大家的时间安排也不够自由。这种**串行开发**的方式过于**同步化**，对于一个追求效率的团队来说是不能接受的。我们需要**高度并行**、**完全异步**的协作开发模式。接下来我们将描述三个典型的并行开发场景，其中的主角是大唐同学和煨鸽同学。 ### 互不依赖且没有修改同一文件例如有个着陆页开发的任务，大唐负责做“关于我们”页面，叫 about-us.html，煨鸽负责做“联系我们”页面，叫 contact.html，这两个文件相互独立的。这里我们假定大唐同学率先完成了任务并且已经合并到 `origin/master` 。这时候根据前一章 **更新本地仓库** 一节的说法，煨鸽正在工作的分支已经“过时”。这时候他只需要继续完成他的 contact.html 页面，然后提交就可以了。这是最简单的，也是最常见的情况（合理的任务划分应当如此）：相互独立的分支只需**依次 push**，不管是否过时。 ### 存在依赖关系且没有修改同一文件现在我们又假设大唐在开发着陆页的首页 index.html，煨鸽负责写着陆页的样式 index.css，很明显大唐的开发任务依赖煨鸽。经过一天的开发，大唐写完了主体部分 `C2`，煨鸽也写好了样式 `C3` 并且已经提交到远程仓库，现在他需要把煨鸽的样式表加进来，才能完成自己的开发任务。 ![](https://cdn.learnku.com/uploads/images/202005/13/28209/ajq5mhwqUH.png!large) 在 [Learn Git Branching](https://learngitbranching.js.org/?NODEMO) 中输入以下代码： ```bash $ git clone $ git checkout -b html $ git commit $ git fakeTeamwork ``` 然后大唐使用 fetch 命令将远程的 C3 抓取下来（其实更严格的说法是将本地的 `o/master` 分支与远程的 `master` 同步）： ```bash $ git fetch ``` ![](https://cdn.learnku.com/uploads/images/202005/13/28209/cPzlfpMrJL.png!large) 可以看到，html 文件的提交和 css 文件的提交在不同的分支上。html 是我们工作的分支（也是当前所在的分支），因此要把 `C3` 所在的 `o/master` 合并过来： ```bash $ git merge o/master ``` ![](https://cdn.learnku.com/uploads/images/202005/13/28209/090yu2tQzE.png!large) 这个形状看上去有点吓人！实际上，你只要真正理解分支的本质就会觉得非常好理解。分支不能简单地理解为一串 commit（虽然说在大多数情况下这种理解非常直观），而应该理解为指向某个 commit 的指针，而该 commit 的所有父节点都是该分支上的节点（commit）。因此在执行合并后，我们可以说 `C2` 和 `C3` 都已经在 `html` 分支上了。合并之后，我们再修改点东西，提交为 `C5` ，然后推送到远程仓库： ```bash $ git commit $ git push ``` > 再次提醒真正的 push 命令在第一次推送某一分支时要加上远程仓库名称和分支名称，例如 `git push origin html` 。接下来就是提交 Pull Request、等待合并就可以了。 ### 修改同一文件首先声明这种情况非常少见，合理的任务划分会尽量避免这种情况出现。但是我们还是会讲解一下这种比较棘手的情况。由于 Learn Git Branching 没有提供冲突（conflict）的演示，所以我们需要自己在本地开仓库进行演示。 > 为什么在本地开仓库练习就可以了，而不需要搭一个远程仓库吗？因为本小节的操作流程和命令跟上一节相比，除了增加了一个处理冲突的步骤，其余完全相同，因此我们关注的重点是怎么处理冲突。 ```bash $ mkdir conflict-demo && cd conflict-demo $ git init $ touch index.js $ git add . $ git commit -m "Add index.js" ``` 然后我们开启一个新分支 `add-func` : ```bash $ git checkout -b add-func ``` 在 index.js 中增添一个 `add` 函数： ```javascript function add(x, y) { return x + y; } ``` 保存并提交： ```bash $ git add . $ git commit -m "Implement add function" ``` 然后我们切回主分支，并开启一个叫 `origin-master` 的分支（听这名字也知道，它模拟了远程的主分支）： ```bash $ git checkout master $ git checkout -b origin-master ``` 接着再在 index.js 中添加一个叫 `multiply` 的函数： ```javascript function multiply(x, y) { return x * y; } ``` 好了，现在本地的 `add-func` 工作分支和“远程”的 `origin-master` 分支修改了同一文件 index.js，冲突一触即发！让我们来点燃这根导火索！ > 其实你可以不停地把分支切来切去（轮流输入 `git checkout add-func` 和 `git checkout origin-master` ），你会看到 index.js 的内容会随之变来变去，版本控制系统的魅力可见一斑。 ```bash $ git checkout add-func $ git merge origin-master ``` 我们会发现 Git 会输出你从未见过的信息： ``` Auto-merging index.js CONFLICT (content): Merge conflict in index.js Automatic merge failed; fix conflicts and then commit the result. ``` 划重点：index.js 在合并时发生冲突，请处理冲突然后提交。我们查看 index.js 的内容，发现了很神奇的东西（在命令行中用 cat 查看）： ``` <<<<<<< HEAD function add(x, y) { return x + y; ======= function multiply(x, y) { return x * y; >>>>>>> origin-master } ``` 如果我们用 VSCode 打开，会看到更炫酷的结果： ![](https://cdn.learnku.com/uploads/images/202005/13/28209/fAXLBtIDkP.png!large) 这就一目了然了！绿色部分是我们当前分支 `add-func` 的内容，蓝色部分是 `origin-master` 的内容。由于我们两者都要，所以点击 Accept Both Changes。然后略经修正，将 index.js 改为如下： ```javascript function add(x, y) { return x + y; } function multiply(x, y) { return x * y; } ``` 提交我们用于处理冲突的 commit： ```bash $ git add . $ git commit -m "Merge conflict of index.js" ``` 冲突处理完成，我们提交此分支，任务完成。 ### 小结并行开发是 Git 团队协作中比较高级却又非常重要的部分。平时大多数情况下，我们遇到的都是第一种情况。如果“不幸”遇到了后面两种情况，不熟悉时可以回来看一看这篇文档。 PS：对于后面两种情况，有一点需要补充：如果想要撤销 merge，使用下面这条命令： ```bash $ git merge --abort ``` ## 提交信息书写规范提交信息，又称为 commit messages 或者 commit logs，是每一步提交所必需的信息。我们可以看一下 React 仓库的提交记录： ![](https://cdn.learnku.com/uploads/images/202005/13/28209/O15oW23ou6.png!large) 由此我们可以对项目每一步做了什么有了比较好的了解。 ### 格式每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。 ```

// 空一行 // 空一行