『Git 干货』#4 GitHub合作开发（简明）

接上文，本文介绍了 Git 基于 GitHub 的使用，以及 合作开发 的注意事项。文章的最后还留下了一些待填的坑

本文大部分内容参考了 RCY 同学的教程，部分参考了 廖雪峰教程-Git ， 菜鸟教程-Git ，以及 Git 官网文档 Git-Documentation 。

以下内容也适用于不同的服务器平台，如 Gitee、GitLab 等。

从 GitHub 上创建一个空仓库后，通常有三个选择：

对于第一种方法，只需要 git clone 命令即可，对于第二种方法，GitHub 提供了一系列指引命令：

对于第三种情况，只需完成后面三步即可。

在通过 GitHub 新建仓库时，我们会发现有个 Add gitignore 按钮，这有什么用呢？实际上我们知道，维护真正项目时可能有一次修改会涉及到多个文件，这个时候一般大家会倾向于使用 git add 的简单 *** 作。

但是，并非所有文件都应该被放入 Git 仓库中，如：

这和便利的命令形成了矛盾，为此出现了特殊文件 gitignore ，它可以决定哪些的文件不需要添加到版本管理中。一个样例如下：

gitignore 是以行为单位，一行写一个规则，决定什么不被添加，书写规则也很简单：

创建一个 gitignore 文件最便捷的方法是，在创建仓库时勾选 GitHub 自动创建，并在选项中选择合适的 gitignore 文件模板，再克隆到本地。当然，也可以选择手动创建，再到网上搜索配置模板。

如果你是在一个 大合作团队 中工作，很可能是 main 被 锁定 了（只有 Collaborators 有权限推送），其他人需要 Pull Request 流程来合并修改。

如果你直接提交到本地 main，然后试图推送修改，你将会收到这样类似的信息:

这里推荐一个做法： Fork 最新的仓库，此时你将拥有这个远程仓库的 从分支 ——你的用户名就是从分支名。再将你的修改提交到这条分支，最后通过 GitHub 网站来提交一个 PR，请求主分支 拉取并合并 你的从分支。

高端的 *** 作往往意味着危险的 *** 作，以下将介绍前文未提及的一些 *** 作，同时也挖下一些坑以后来填。

有时候你可能希望放弃 Git 仓库中的一部分提交，退到其他某处，这种情况下可以：

这种情况下可以带着分支一起回退，然后重新 commit，走一条完全不同的道路，而放弃了部分数据。

但是，如果你 reset 完后又后悔了，该怎么办？没关系，只要你没玩 gc 这样的危险指令，那么你 Git 仓库中的数据总有机会找回来。

在看到后面的快照的版本号后，则可以 reset 回去。

一个相对高端的分支管理命令，将一些提交复制到当前所在的位置（HEAD）下面，这些提交可以来自其他分支，但不一定是顺序的！

用于将目前暂存区的东西移入一片额外空间，从而清空暂存区。

无论是本博客，还是网上的文档，甚至官方的教程，都未必能把每个指令的每个参数、用法提到，因此 Git 自带的帮助文档就很重要：

---