General Question

请问任何同学提交pr都会被review吗？我是其他学校的学生，发现您们的repo很有帮助，想参与学习。

What problem does this PR solve?

What have you done or changed in this PR?

What test did you complete before submitting the PR?

Above is the current PR template. In order to standardize the PR format, some fields can be added:

• Who participate in this PR？

General Question

1. Is this plan designed specifically for Postgraduate? I can't believe an freshman of bachelor student without any basics in computing can handle this plan (
2. Can outsiders interested in distributed or databases participate in the learning of this Lab? Your courses are really interesting and challenging :-)

General Question

关于新生学习计划training-plan后续发展与管理的讨论与记录，包括但不限于仓库版本纪要、仓库组织框架，作业规范，重要管理命令，对外使用，如果有需要优化的地方一起讨论：

仓库版本纪要

2019-07-06

仓库上线#11🚀

2021-01-13

2020级归档[#28 ,training-plan-2020]:baby:

仓库组织框架

每一级从template分支拉一个私仓开始学习计划，结束后整理归档回公仓，及时对template和homework打上tag。

• tag命名形式
  homework2020
  homework2021
  homework2022
  template2020
  tempalte2021
  tempalte2022
• 分支结构
  ├─master // 目前是2020级的作业，后续可以改名
  ├─template // 计划模板，应不断更新，与时俱进
  ├─training_plan_2020 // 20级归档
  ├─training_plan_2021 // 21级归档
  └─training_plan_2022 // 22级归档

作业规范

代码规范

google-cpp-style
google-python-style
uber-golang-style
...

PR规范

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

重要管理命令

从template拉取私仓

1. github上新建一个私仓
2. 添加公仓作为 public remote
   git remote add public [email protected]:CDDSCLab/training-plan.git
3. 切到public/template
   git checkout public/template
4. 将public/template push到新建的私仓上面

从私仓中cherry-pick做得好的PR

1. 添加私仓作为remote
   git remote add private git://gitUrl
2. 拉取不合并
   git fetch private
3. 查看想要pick的brachname的log
   git log private/branchname
4. cherry pick
   单个commit:git cherry-pick <commitHash>
   多个commit:git cherry-pick <HashA> <HashB>
   [A,B): git cherry-pick A^..B

git submodule的使用

一些项目可能是放在同学自己的个人仓库上面的，可以使用submodule的形式进行链接。

• 添加submodule

1. --name增加名字
   git submodule add git://gitUrl path-to-submodule

• 移动submodule

1. 下面命令能改变.gitmodules每个submodule的path，submodule名字不会改变，可以手动改变
   git mv path-to-old-submodule path-to-new-submodule

• 删除submodule

1. Delete the relevant section from the .gitmodules file.
2. Stage the .gitmodules changes:
   git add .gitmodules
3. Delete the relevant section from .git/config.
4. Remove the submodule files from the working tree and index:
   git rm --cached path_to_submodule(no trailing slash).
5. Remove the submodule's .git directory:
   rm -rf .git/modules/path_to_submodule
6. Commit the changes:
   git commit -m "Removed submodule <name>"
7. Delete the now untracked submodule files:
   rm -rf path_to_submodule
   • refs

• 克隆使用含有submodule的项目
  包含对应的空目录需要使用以下两个命令

1. git submodule init
2. git submodule update

对外使用

Fork,Issues and PR are welcom.
MIT License.

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 到团队的代码库中，你的贡献达成。