让 Python 带你进入开源的世界——Git 从入门到与他人协做开发

让 Python 带你进入开源的世界——Git 从入门到与他人协做开发

我认为开源社区中有不少优秀的资源，而且能够帮助进阶中的程序员提升编程能力和水平。因此，我发起了《HelloGitHub》月刊，同时开始编写《让 Python 带你进入开源的世界》系列，但愿更多的小伙伴加入到开源的社区当中。我我的能力有限，分享的知识都是经过我认真的收集、整理、总结、编写，若是认为本文还不错，那就欢迎持续关注，并加入到其中 😁。下面就是正文了：

本篇分为三个阶段：领进门（新手）、搜肠刮肚的建议（进阶）、后续的我的修行，因此能够根据自身状况经过下面的目录进行选阶段阅读。

建议： 若是是新手的话，请依次完成每一部分的实践经过后，再学习下一部分。

目录

• Git 入门
  • Git 和 GitHub 的关系
  • 实践
• Git 基本使用规范
• Git 工做流
  • Git 工做流1（非项目内成员）：多用于为 GitHub 上的开源项目贡献代码
  • Git 工做流2（项目内成员）：经常使用用于工做中
  • 编写优秀的 commit 信息
  • 实践
• 更多 Git 使用技巧
• 建议收集
• 参考

1. Git 入门

Git 是一个“分布式版本管理工具”，简单的理解版本管理工具：你们在写东西的时候都用过“回撤”这个功能，可是回撤只能回撤几步，假如想要找回我三天以前的修改，光用“回撤”是找不回来的。而“版本管理工具”能记录每次的修改，只要提交到版本仓库，你就能够找到以前任什么时候刻的状态（文本状态）。

1.1 Git 和 GitHub 的关系

Git 是一个“分布式版本管理工具”，这里须要理解分布式。也就是每一个用户会有一个本地仓库，同时还有一个远程仓库。而 GitHub 就是用户远程仓库的托管网站。不一样用户能够复制同一个仓库的代码到本地，而后开发某一部分功能，完成后提交请求到远程仓库。若是合并成功，后面用户再获取、更新该远程仓库的代码，就会包含你开发的功能，从而达到多个用户同时开发不一样模块互不影响的效果。

例如：Gitlab、Bitbucket、自搭建的 Git 服务器等，都是一样的道理。

因为篇幅问题，我把 GitHub 入门 部分提早写出来了，能够在后面的实践部分阅读。

1.2 实践

参考我写的 GitHub 入门教程，还有我推荐的 Git 极简入门教程

1. GitHub 入门教程：先建立帐号，到第四步在参考下面的教程。
2. Git 极简入门教程：在上述教程中建立的项目中，练习本教程中的命令，并理解其做用。

练习：

1. 请跟着 GitHub 入门教程 的步骤，建立项目并提交修改。
2. 阅读 Git 极简入门教程，建立一个任意分支，并推送到远程仓库。
   最后，点击这里，提交你建立的项目地址。

我会及时给出回复。若是完成了上述步骤并经过，你就能够阅读下面的章节了。

2. 基本规范

本部分翻译修改自：project-guidelines

首先，不论是项目的管理者或贡献者，都须要了解的一些基本规则：

• 从 develop 分支建立新的分支

  缘由：

  这样能够确保 master 分支老是没有问题的，从而能够直接运行或者发布。同时由于 develop 分支是开发的主分支，能够确保全部子分支都是继承于同一分支开发。

• 建立 feature 分支开发新的功能

  缘由：

  由于这样全部的工做都是在专用分支（feature）而不是主分支上，使得彼此的工做是彻底隔离的。它容许你随意提交请求而不会影响其余人的开发。你能够实时迭代你开发的功能，即便这些代码是未完成，也不会污染和影响公共分支。

• 经过 Pull Request 方式提交代码到 develop 或 master，不要直接 Push

  缘由：

  由于 PR 的方式能够通知全部团队成员你已完成该模块的功能，还能够轻松地对代码进 Review，并能够在该 PR 下讨论功能和交流。

• 同步本地的 develop 分支到最新，而后经过 rebase 命令合并到你的 feature 分支，最后提交 PR

  缘由：

  由于，在 feature 分支上，经过 rebase 命令合并 develop 分支是不会产生额外的 commit（假设没有冲突），从而能够获得一个干净整洁的提交历史。

• 先经过 rebase 命令解决冲突，而后再提交 Pull Request

• 提交经过后删除本地和远程的 feature 分支（项目内成员）

  缘由：

  由于，分支过多会形成没必要要的混乱和重复提交，要记住 feature 分支只存在于开发进行时。

• 在提交 Pull Request 以前，确保你的分支代码运行没问题而且经过测试（包括代码风格检测）

  缘由：

  你将要提交代码到稳定的分支，若是你的功能分支测试失败，那么一样的会致使目标分支运行、测试失败。与此同时，PR 以前你还须要检测代码是否有代码风格检测，这样作的目的是为了让整个项目的代码更加易读、统一。

• 记得设置 .gitignore 文件

  缘由：

  有了 .gitignore 文件，就能够把运行过程当中或者 ide 产生的并非项目自己的文件过滤掉。

• 把 develop 和 master 分支设置为保护

  缘由：

  它保护你的生产和开发分支免受意外和不可挽回的错误。更多现详情能够阅读，GitHub 关于 protected 的说明

3. Git 工做流

工做流分为：

1. 工做流1（非项目内成员）：未被邀请进项目，也就没法直接建立分支
2. 工做流2（项目内成员）：已经被邀请进项目，能够直接建立分支

GitHub 上为开源项目提交代码就用：非项目内成员工做流

工做中大多使用：项目内成员工做流

两种工做流，相差的并很少，推荐先学习 工做流1。

3.1 Git 工做流1（非项目内成员）

由于不是项目中的成员，没法直接修改项目中的代码。因此须要先拷贝（Fork）项目到本身的远程仓库中（GitHub帐号下），而后基于本身克隆过来的项目开发新的功能，最后提交 PR。

project_url：想要贡献代码的项目地址（源地址）
fork_project_url：克隆到本身远程仓库的项目地址

• Fork 项目
  sh 项目首页 "Fork"
• 下载项目
  sh git clone fork_project_url
• 增长源项目仓库地址
  sh git remote add <origin-name> project_url
• 切换到 develop 分支
  sh git checkout develop
• 建立新的 feature或bug-fix 分支
  sh git checkout -b <branchname>

• 保存你的修改（开发、修复bug）
  sh git add git commit -a
  缘由：

  git commit -a 命令中的 -a 参数是开启编辑器编辑 commit 信息，会在后面有详细的说明。

• 更新到与远程仓库同步
  sh git checkout develop git pull --rebase <origin-name> develop

• 把最新的 develop 分支经过 rebase 命令合并到 feature 分支和对应的远程分支
  sh git checkout <branchname> git rebase -i --autosquash develop

  缘由：

  你能够经过 --autosquash 命令把多个 commit 压缩成一个 commit，这样是的历史更加整洁，一个功能就一个commit。经过 rebase 在本地就把冲突解决好，以免提交 PR 时才发现冲突，致使提交失败。

• 若是在合并时没有出现冲突（conflict）就跳过这步；若是有冲突，能够先修改文件中的冲突，而后执行下面的命令。
  sh git add <file1> <file2> ... git rebase --continue

• Rebase 命令会修改历史，因此你 push 时可能会须要加上 -f 强制修改历史。若是有其余人也在你的分支上开发，就使用 --force-with-lease 减小破坏
  sh git push -f

  缘由：

  由于只是修改 feature 分支的历史，并且每一个 feature 是独立（理论上只有一我的开发），因此在 push 时加上 -f 参数并不会影响其余人的工做。

• 提交 Pull Request
• Pull request 被接受、合并完成，就关闭该评论

• 如上述步骤都已完成，删除你本地和远程的 feature 分支

  git branch -d <branchname>
  git push origin --delete <remote-branchname>

3.2 Git 工做流2（项目内成员）

这种工做流，更适合用在工做中。

• 下载项目
  sh git clone project_url
• 切换到 develop 分支
  sh git checkout develop
• 建立新的 feature或bug-fix 分支
  sh git checkout -b <branchname>

• 保存你的修改（开发、修复bug）
  sh git add git commit -a
  缘由：

  git commit -a 命令中的 -a 参数是开启编辑器（vim基本操做）编辑 commit 信息，会在后面有详细的说明。

• 更新到与远程仓库同步
  sh git checkout develop git pull --rebase

• 把最新的 develop 分支经过 rebase 命令合并到 feature 分支和对应的远程分支
  sh git checkout <branchname> git rebase -i --autosquash develop

  缘由：

  你能够经过 --autosquash 命令把多个 commit 压缩成一个 commit，这样是的历史更加整洁，一个功能就一个commit。经过 rebase 在本地就把冲突解决好，以免提交 PR 时才发现冲突，致使提交失败。

• 若是在合并时没有出现冲突（conflict）就跳过这步；若是有冲突，能够修改文件中的冲突，而后执行下面的命令。
  sh git add <file1> <file2> ... git rebase --continue

• Rebase 命令会修改历史，因此你 push 时可能会须要加上 -f 强制修改历史。若是有其余人也在你的分支上开发，就使用 --force-with-lease 减小破坏
  sh git push -f

  缘由：

  由于只是修改 feature 分支的历史，并且每一个 feature 是独立（理论上只有一我的开发），因此在 push 时加上 -f 参数并不会影响其余人的工做。

• 提交 Pull Request
• Pull request 被接受、合并完成，就关闭该评论

• 如上述步骤都已完成，删除你的本地 feature 分支
  sh git branch -d <branchname> git push origin --delete <remote-branchname>

3.3 编写优秀的 commit 信息

制定良好的建立 commit 规范，并坚持使用，使得与他人合做更容易。下面是一些经验和建议：

• 把 commit 信息分为 标题和内容两个部分，二者之间要有个空行

  缘由：

  Git 可将你的提交消息的第一行作为摘要

• 标题控制在 50 个字符之内，内容最多不超过 72 个字符

  缘由：

  commit 信息尽量简洁和精准

• 标题首字母大写
• 标题不要有句号
• 标题使用“祈求语句”

• 内容中解释为何要有此次提交、如何解决问题、可能影响的地方

  缘由：

  若是有需求、issues地址、能够附上。更多详情

3.4 实践

本节就一个实践内容，可是并非很简单，请仔细阅读并遵照：

向个人 test_project 项目的 develop 分支提交一个PR，要求以下：

1. 在 README.md 文件中新启一行，增长内容为上一个 commit 的 id 号
2. Commit 信息要按照上述 3.3 节要求书写

提示： 可能会由于接受提交顺序而产生冲突，如遇到冲突，要解决完冲突后从新提交。如遇问题，可参考 “4. 更多 Git 使用技巧”。

4. 更多 Git 使用技巧

俗话说：师傅领进门修行靠我的。

用好一个工具或技能最好的方式就是不断的使用，使用中必然会出现问题。当你解决了足够多的问题，你也就成为老司机了。

遇到问题：

• 请先阅读错误提示
• 经过搜索引擎寻找答案（国内推荐使用 bing 搜索技术问题）
• 用本身的语言经可能详细的描述问题，并收集充足的信息后，在询问老司机

最后，请拿走这本秘籍：git-tips，😄

5. 建议收集

本教程确定还有不足的地方或者你以为好的地方，欢迎自由留言积极讨论，但愿这个系列可以帮助到更多的小伙伴！

• 本教程很差的地方？
• 是否须要提供视频教程？
• 零基础入门是否感受到吃力？

参考

• project-guidelines
• autosquashing-git-commits
• Git 写出好的 commit message