CDUTCMOJ中的README.md

Posted on Edited on Symbols count in article: 2.5k Reading time ≈ 2 mins.

CDUTCMOJ是一个托管在Gitee上的repository，里面存放着CDUTCMOJ的题解。一个repository中，README.md负责介绍本repository的愿景、内容、FAQ等。以下内容摘录自CDUTCMOJ中的README.md。

愿景

相互学习，共同进步🎉🎉🎉

文件组织方式

目前本仓库的文件组织方式如下：

  • Tom
    • README.md
    • 1001.cpp
    • 1001.py
    • 1002.cpp
  • Amy
    • README.md
    • 1001.py
    • 1002.java
    • 1008.cpp
    • 1009.c
  • Lucy
    • README.md
    • 1001.c
    • 1009.java
    • 动态规划类题目的解题小技巧.md

每位contributor的题解在自己的文件夹内，这样每位同学由自己的命名空间，自主空间会更大些。

现在大部分的code editor和IDE都具备强大的文件搜索功能，所以需要借鉴题解的同学可以直接通过搜索的方式访问所有其他同学的题解。

如何协作？

如果你觉得小鹏（Gitee用户名：joy）对于第1001题的题解存在可改进的地方或bug，你应当这样做：

  • 基于小鹏的contributor/joy分支创建一个名为bugfix/joy/1001或enhancement/joy/1001的分支，

  • 在上一步创建的分支上进行更新

  • 提交pull request（该pull request的Assignees必须包括小鹏！Assignees可在下图红框处进行设置）

    image-20220215225840033

如果小鹏认同你的更新，那么小鹏应将你创建的分支合并到自己的contributor/joy分支，并将local repository和remote repository同步。

请注意：通过pull request，你在将**bugfix/joy/1001或enhancement/joy/1001分支合并到小鹏的contributor/joy分支前，向团队开放了一个讨论，这样有助于让团队（尤其是小鹏本人）知晓你的建议。不要将你的分支直接合并到小鹏的contributor/joy分支**，这样会给团队（尤其是小鹏本人）造成不必要的困惑。

如何命名？

commit message #guideline

  • Add answer to 1001
  • Add answers to 1001, 1002
  • Fix the bug(s) in the answer to 1001
  • Fix the bugs in the answer to 1001, 1002
  • Refactor code

请注意：本规范只是guideline，用于协助大家写出更有意义的commit message，而不是rule。本仓库有别于软件开发类的仓库，对于good history的需求并不强，因此写成提交时的日期也是ok的（在微软拼音下输入日期，然后再按5）。

branch #rule

If you are serious about contributing to this repository, you need to follow these rules.

  • contributor/Anders-Hejlsberg
  • bugfix/Anders-Hejlsberg/1001
  • enhancement/Anders-Hejlsberg/1001

pull request #rule

If you are serious about contributing to this repository, you need to follow these rules.

  • Bugfix: Fix the bug(s) in the answer to 1001
  • Bugfix: Fix the bugs in the answers to 1001, 1002, 1003
  • Enhancement: Enhance the answer to 1001
  • Enhancement: Enhance the answers to 1001, 1002, 1003

Workflow

  1. 克隆本仓库
  2. 创建自己的分支
  3. 在自己的分支上更新代码并保存
  4. 提交commit
  5. 将commit push 到remote
  6. 发起pull request
  7. 将自己的分支merge到master分支
  8. 3-6循环

FAQ

GitHub访问速度较慢，影响协作体验，为什么要将本仓库托管到GitHub？

GitHub的GitHub Desktop对于Git新手比较友好，而Gitee未开发同类软件。

本仓库内的《Git光速入门》的是一份Git学习资料，当本仓库的维护者们对Git的熟练度达到更高的level时，我们可以考虑下是否要将我们的代码托管和协作开发平台由GitHub更改为Gitee。

鉴于GitHub访问速度实在太慢:cry:，目前本仓库已托管到Gitee。

为什么本仓库目前是private状态？

主要的原因是private状态下的workflow相对简单一点。

open source project的workflow一般是这样的：

contributor

  1. fork the project repository
  2. clone your forked repository
  3. make a few commits to your local repository
  4. do a push to send your commits to your forked repository when you are ready to share your work
  5. send a pull request to the maintainers of the project

maintainer

  1. gets notified about the pull request
  2. pull in the changes of the contributors and review them
  3. merge the contributors’ work into your local repository
  4. push the merged changes to the official repository

希望我们的项目能够快快成长，最终达到较高的水准，然后挑个好日子开源。

plus：在将本仓库设为public前，我们需要为本仓库选择一个合适的license。