GitHub协作开发项目
文章目录
注：转载请标明原文出处链接：https://xiongyiming.blog.****.net/article/details/106056200
以前用GitHub只知道搜索代码然后下载看是否使用，也不知道GitHub其他的功能。最近了解了GitHub相关功能，觉得GitHub太厉害了，微软75亿美元收购GitHub真的太值了。
Github可以协作开发项目，官方文档给出了操作流程： Understanding the GitHub flow
下面将简单介绍文件内容，然后通过两个例子来模拟Github协作开发项目，方便后期复习查阅。
1 了解GitHub flow
1.1 创建分支(Create a branch)
当你在进行项目开发时，在任何给定的时间都会有许多不同的想法，其中一些可能已经完成，而另一些则没有完成。分支可帮助你管理你的项目。
当你在项目中创建分支时，你正在创建一个可以尝试新想法的环境。你在分支上所做的操作不会影响主分支内容，因此你可以自由地进行试验和提交更改，审核后进行合并为止。
ProTip
分支是Git中的核心概念，整个GitHub流程都以此为基础。只有一条规则：master分支中的任何内容始终都是可部署的。
因此，在处理功能或修订时，要在主分支之外创建新分支非常重要。 你创建的分支名称应具有描述性（例如，refactor-authentication, user-content-cache-key, make-retina-avatars），这样方面其他人可以看到正在处理的内容。
1.2 添加提交 (Add commits)
创建分支后，就可以开始进行更改了。无论何时添加，编辑或删除文件，都在进行提交，并将其添加到分支中。添加提交的过程可以跟踪您在功能分支上工作的进度。
提交还会保留历史记录，其他人可以遵循该历史记录来了解您的工作以及原因。每个提交都有一个关联的提交消息，该消息是说明为什么进行特定更改的说明。此外，每次提交都被视为一个单独的更改单元。如果发现错误，则可以反复进行更改。
ProTip
提交消息非常重要，尤其是因为Git会跟踪您的更改，然后将它们显示为提交后将其显示在服务器上。 通过编写清晰的提交消息，您可以使其他人更容易跟进并提供反馈。
1.3 提出请求 (Open a Pull Request)
自己在分支上提交代码后，觉得还不错可以发送请求，送给对方审核，对方审核通过则可以进行合并。
1.4 讨论和审核你的代码 (Discuss and review your code)
管理者打开“提出请求”后，将会对你的代码进行审核，如果有问题可以回复对方修改，直到满意为止。
ProTip
提出请求是用Markdown编辑器进行编辑的，编辑的内容不局限于文本，可以是图片，代码等内容。
1.5 部署 (Deploy)
使用GitHub，你可以从分支进行部署，即正式合并之前进行最终测试。
如果管理者觉得可以就进行合并。
1.6 合并(Merge)
现在您的更改已在生产环境中得到验证，可以将代码进行合并带master分支中。
合并后，提出请求会保留代码历史更改的记录。 因为它们是可搜索的，所以它们使任何人都可以及时返回以了解做出决定的原因和方式。
下面针对上面的原理通过简单的例子进行实践。
分为两种情况：
第一种是团队之间互相认识，共同开发项目。这样可以建立私人项目，然后邀请项目成员共同开发，这样其他人将看不到团队的项目。
第二种是开源的项目，全网都可以看到，大家都可以对你的项目提出建议和修改，达到共同开发的目的。
2 团队协作开发
例如：团队成员有：luohuayouyi66 和 xiongyiming 等人。项目需要团队成员共同开发，项目负责人为luohuayouyi66。那么luohuayouyi66需要在GitHub上新建仓库然后邀请团队成员开发项目。
2.1 新建项目(仓库)
新项目创建好后，需要创建分支，分配给项目成员。
Settings ——> Manage access ——>Invite a collaborator
收到邮件，接受邀请.
这样团队成员xiongyiming 既可以看到这个私人项目 test_teamwork 。
2.2 创建分支
下面还需要创建一个分支add_hello_world ，分配给项目成员xiongyiming 进行操作。
这样，就出现了新的分支 add_hello_world 。
2.3 项目成员在新分支上提交代码
私人项目地址： https://github.com/luohuayouyi666/test_teamwork
此时团队成员完成操作。
2.4 发送请求
团队成员xiongyiming完成了自己的任务，希望负责人检查自己的代码并合并分支，来表示自己的操作合格。此时需要发送请求。
2.5 讨论与审核代码
此时，需要等待项目负责人的审核，若果没问题就可以直接合并。自己合并和项目负责人合并都可以。
下面是项目负责人luohuayouyi666看到团队成员xiongyiming发送的请求。
此时发现有拼写错误，并不能合并，要求团队成员重新修改。
此时，团队成员xiongyiming账户上出现消息。
需要重新修改代码
代码改好了之后，不需要再重新发送请求了，直接在消息后面回复即可。
此时，项目负责人账户就会看到团队成员xiongyiming的修改内容并进行审核。
如果觉得没问题就可以选择合并分支。
2.6 合并分支
此时，master 分支上就会出现新增的代码文件，这就是合并分支的效果。
然后，建立的分支也可以直接删除。
此时，add_hello_world 分支被删除后，项目只有一个 master 分支的，这样就完成了一个简单团队协作开发项目的操作了。
3 开源项目协作开发
开源项目协作开发就是自己的项目公开放在GitHub上，陌生人看到你的项目就可以Fork你的项目，然后更改内容，此时自己的项目(原作者的项目)不会发生变化。如果陌生人觉得更改的内容可以放进原作者的仓库中，就可以发送请求，原作者可以审核并判断是否可以合并。
开源项目协作开发和团队协作开发的区别在于，前者是和陌生人共同开发，后者是团队之间认识的人协作开发。在开发的过程中，团队之间协作开发可以邀请团队成员，而墨人生需要Fork项目之后才能进行更改，其他的操作二者之间原理相似：
创建分支——>提交代码——>发送请求——>讨论与审核——>合并分支
下面举个简单的例子来说明开源项目协作开发：
假设用户luohuayouyi666仓库中公开了一个项目: test_develop
用户xiongyiming在网上看到该项目觉得挺有意思并觉得还可以在升级，就Fork该项目并修改代码，此时希望原作者luohuayouyi666可以看到自己更改的代码并希望可以合并，就向作者发送请求。
下面具体来进行操作。
3.1 新建项目(仓库)
用户luohuayouyi666创建项目(仓库)：test_develop
新增项目文件 hello_world.cpp
3.2 Fork
用户xiongyiming发现用户luohuayouyi666创建项目(仓库)：test_develop ，觉得该项目挺好，可以再升级开发，于是需要Frok该项目。
此时，Fork该项目成功，这样可以对该项目随意修改，不会影响原作者的项目内容。
3.3 创建分支
用户xiongyiming发现该项目程序代码出现拼写错误，并且向增加一个代码文件，则可以创建分支直接修改。对于错误代码文件直接修改，选择创建分支进行增加其他代码，。
第一种类型： 直接修改 hello_world.cpp 文件中的错误并发送请求。
修改好了项目原作者发送请求。
发送请求成功后，原作者账户luohuayouyi666看到请求。
此时原作者可以查看修改了哪些内容，并可以向该用户讨论。
觉得没问题的话，就可以合并该请求。
接下来就合并成功了，自己的开源项目得到进一步的完善。
查看提交记录，可以看到用户的修改以及合并的记录。
第二种类型： 用户xiongyiming在Fork的项目上创建分支 add_test_sum，并添加自己的代码 test_sum.cpp文件
此时，分支 add_test_sum 创建成功。下面将在分支下提交自己的代码。
3.4 提交代码
代码提交成功，如下图所示，该分支下面出现新增加的 test_sum.cpp 文件
3.5 发送请求
代码提交成功后，希望原作者可以合并，需要提交请求。
发送请求成功如下图所示，下面就需要原作者进行审核。
3.6 讨论与审核代码
原作者luohuayouyi666账户可以看到用户xiongyiming发送请求，可以进行查看并审核。
3.7 合并分支
如果觉得代码没有问题就可以合并分支，将分支 add_test_sum 合并到 master 分支上。
合并成功后，查看该项目下新增了一个 test_sum.cpp 文件，这样开源项目又得到了进一步完善。
用户xiongyiming可以删除原来的分支 add_test_sum，若想再进一步完善该项目，可以重新Fork该项目，因为有时候原项目有其他用户进行开发，为了方便自己知道是否和其他用户修改的内容发生冲突，可以重新Fork该项目，从而更了解别人开源项目的进展。
4 总结
GitHub协作开发项目可以分为团队协作开发和开源项目协作开发，前者项目成员之间互相认识，后者成员之间可能不认识。其实二者在操作时本质上的区别并不大。协作的主要几个步骤为：
创建分支——>提交代码——>发送请求——>讨论与审核——>合并分支
关于GitHub其他使用可以参见：
[1] Github初步使用
[2] GitHub下载加速
参考资料
[1] Understanding the GitHub flow
[2] 版本控制入门 – 搬进 Github