关于实验室项目多人协作开发流程的讨论

[ehds]

General Question

关于实验室项目多人协作（例如作业提交）的工作流程，拟定如下步骤，如果有需要优化的地方一起讨论：

协作开发流程

我们的项目的协作主要使用 PR (pull request) 的方式 来完成，每位开发者在自己的 branch 上完成开发、测试等工作，然后将新的修改进行 PR，这样可以方便代码 review，通过后再 merge 到 master 上，保证 master 分支的提交历史清晰整洁且符合一定的规范。

下面是一般的协作流程：

1. 创建新的项目仓库

首先管理者在组织下建立一个新的项目仓库，名称尽量使用英语单词，并完善 README、LICENSE、gitignore、template等必要文件。

2. fork 仓库

每个开发者需要从该组织的项目仓库中 fork 一个分支到自己的仓库里面，此时自己仓库会存在一个名称相同的项目，并且默认的分支为 master, 注意该 master 分支仅作为与组织所在的 master 的同步作用, 不要在上面进行开发流程。

3. 本地仓库的构建

此时所有的分支都在 Github 的远端，在本地需要先将它们 clone 。如：

你自己的仓库的地址为 [email protected]:nickname/project.git

组织的仓库地址为 [email protected]:team/project.git

注意：在后面的命令中注意替换 nickname 和 team 为实际的名称。

那么需要将两个仓库都要加入到本地中：

​ git clone [email protected]:nickname/project.git

​ 上面的命令会自动将自己仓库的地址进行同步（包括 fetch 和 push）

​ git remote add team [email protected]:team/project.git

​ 上面的命令会将 team 的项目地址更新 （包括 fetch 和 push )

4. 同步 master

因为是团队协作开发，所以当一段时间后你自己仓库的 master 已经落后于团队的 master，所以在你开启一个新的工作的时候，需要更新 master。

git checkout master
git pull team master

上面的指令首先切换本地分支为 master 、然后 pull 团队的 master 分支，如果本地的 master 没有其他操作，pull 应该是能够成功执行的，所以切记保持自己这边的 master 仅作为同步使用。

5. 开启新的分支展开工作

此时可以开始自己的工作了，首先开启一个新的分支, 分支的名字最好能够描述你的工作内容，如新加了一个 feature：

git checkout -b feature

注： -b 代表不存在该分支则自动创建

此时 feature 分支就从最新的 master 上分了出来，后续的开发就可以在这个分支上进行。当然如果有一些紧急的某个 bug 需要解决，那么同样先更新 master，从 master 上 git checkout -b fix-bug ,在 fix-bug 分支上解决 bug ，待完成后，可以切换到feature 分支上继续开发 git checkout feature

每当你完成一个阶段任务时记得 commit 你的修改

git add . 添加所有修改，或者 git add file1 file2 添加特定地文件，此时你的修改会被保存到工作区，然后 commit 你的阶段性工作

git commit -m "message" message 填写你的阶段性工作地描述

此时你的 commit 会被记录到提交的历史中，使用 git log进行查看。这样的方式方便你查看历史的修改，还可以回退到之前的某次提交中，便于管理。

6. PR 你的工作

当你完成你的工作后，那么就可以得意地将你的工作贡献到团队的项目中。首先确保你本地已经 commit 了你想要 PR 的修改，然后 push 本地分支到远端。

git push -u origin feature

注：-u代表将你本地的分支和远端的分支进行绑定，一般情况下本地的分支名字和远端的名字保持一致。

此时你的远端仓库中会多一个同名的 feature 的分支，此时就可以点击 Pull requst -> New pull request，选择 head repository 的分支为你要 PR 的分支 如 feature , 完善 PR 的相关信息，确认后等待审核就可以了。记得按照要求人数选择你想要被 review 的 member（可以是你的组长或者师兄，最好是和你工作重合度较高的人），并打上匹配的标签。

7. 优化你的工作

可能在 review 的过程中，你的工作还会存在一些问题需要修改，review 的同学会将你所存在问题列出来，你需要回到工作环境中完成相关的修改，然后再重新 commit 和 push 就可以了，因为此时你的分支已经进入 PR 流程，不需要再创建新的 PR， 当前的 PR 会自动更新你的修改。

如果通过 review ，后续团队的 member 会将你的 PR merge 到团队的代码库中，你的贡献达成。