python之git----- GitHub

python之git----- GitHub

一：github原文链接
https://guides.github.com/activities/hello-world/

二：What is GitHub?
GitHub 是一个版本控制和协作的代码托管平台
1，创建仓库
仓库通常是用来组织一个项目的。仓库可以存放文件夹、文件、图片、视频、电子表格还有数据集 —— 任何你的项目需要的内容

a>在页面的右上角，点击头像隔壁的“+”号，选择 New repository

b>将你的仓库命名为 hello-world

c> 为该项目写上一段简短的描述

d>勾选 Initialize this repository with a README（为该仓库初始化一个 README 文件）

e>最后点击 Create repository

2,创建分支
通过分支的方式，允许你在同一时间对仓库不同版本的内容进行操作;建立不同的分支进行测试和编辑，完善以后再提交至 master；master 建立一个分支时，你拷贝的是当时 master 分支里的内容。
master 分支:主分支
a> 来到你的新仓库 hello-world 中
b>点击那个叫做 main: 下拉按钮 输入readme-edits
c>单击 Create branch 或直接回车键走起
现在你拥有了两个分支：master 和 readme-edits
3,提交修改
位于 readme-edits 分支的代码视图,它是拷贝自 master 分支的
GitHub 上，保存修改被称为提交（commits）。每次提交都有一个关联的提交信息，用于描述你做所的修改。
a>点击 README.md 文件

b>点击文件视图右上角的铅笔图标进行编辑

c> 在编辑框中，随便写一些东西

d> 在下边填写提交信息并描述你的修改

在分支上修改只影响了 readme-edits 分支的 README 文件，而 master 的 README 文件并没有被改变，所以现在两个分支的内容已经不同了。

4，发起 Pull Request
Pull Requests 是 GitHub 实现合作的核心。（当你发起一个 pull request 的时候，表示你希望别人将你修改的内容进行审查然后合并到他们的分支中去）
A>Pull Requests 会显示每个分支的不同之处，添加（绿色）和删减（红色）的地方都会显示出来
B>通过使用 GitHub 的 @ 通知系统，你可以获得指定小伙伴或团队（无论他们身在何处）对 pull requset 的反馈消息

步骤：
a>点击 Pull Request 标签，然后在 Pull Request 页面中点击 New pull request 按钮

b>选中 readme-edits 分支，用于和 master（原始）分支进行对比

c>在对比页面查看两个分支的不同，确保你希望提交的内容正确
d>当你确认所有待提交的内容正确无误之后，点击页面上方那个绿色的按钮 Create Pull Request
e>为你的 pull request 操作写一个标题以及简短的说明

5,合并你的 Pull Request

a> 点击绿色按钮 Merge pull request 将修改的内容合并到 master 分支中

b>点击 Confirm merge 按钮

c> 点击紫色框中的 Delete branch 按钮删除分支，因为它已经合并进来了。


三：理解 GitHub 流
GitHub 流是一个轻量级的、基于分支的工作流，它使得团队和项目的部署更有条不紊
下面解释 GitHub 流是如何工作的

*创建一个分支：*项目创建一个分支时，你实际上创建的是一个允许你尝试新想法的环境
注意：
1，创建一个分支-分支是 Git 的核心概念，整个 GitHub 流也是在基于分支的基础上建立的。记住只有一条规则，主分支上的任何东西总是可以被展开的
2，分支创建完毕，就可以开始做一些更改了。每当你进行添加、编辑或删除一个文件时，都会提交并添加到你的分支里。当你在开发新功能的分支上工作时，添加提交的过程会跟踪你的工作进度。
3，添加提交-提交信息很重要，尤其是在 Git 跟踪了你的更改，并将他们提交到服务器并显示在小伙伴们的客户端时……如果有了明确的提交消息，就可以使得他们更容易理解你的想法并提供反馈。
4，发起 Pull Request --Pull Requests 不仅有助于开源项目的开发，也使得共享仓库的改动管理更加轻松。如果你使用分支推送模式（Fork & Pull Model），通过 Pull Requests，你可以将自己的更改建议通知给项目维护者；如果你使用共享仓库模式（Shared Repository Model），在改动被纳入主分支之前，Pull Requests 也方便了彼此之间的代码审查和改动内容的交流。
5，讨论和审查你的代码-Pull Request 评论是使用 Markdown 来写的，所以你可以嵌入图片和 emoji 表情，使用预格式化的文本块和其它轻量级的格式。
6，部署-pull request 经过审查，并且对应分支通过了测试，这时你就可以在产品中部署你的改动并且验证。如果此分支造成了某些问题，你仍然可以退回到之前的产品进度。
7，合并-Pull Requests 会为你的代码的历史更改保留一份记录。因为它们必须是可搜索的，这样任何人都可以回到过去，了解为什么以及如何会做出这样的决定。

四：创建你的 GitHub 主页
1,setting -->“Commit changes”按钮

五：典型的项目

1,社区（The Community）
每个项目通常都有一个相关联的社区，由其他用户扮演（正式或非正式）的角色组成：

所有者是指创建项目的个人或组织，该身份拥有这个项目
维护者和协作者是指这个项目的主要开发者和推动项目开发方向的人，通常项目所有者和维护者是同一个人，他们都拥有仓库的写入权限
贡献者是指任何对项目开启 pull request 并被合并到项目中的人
社区成员是指经常使用这个项目，深切关心项目并且活跃讨论项目的功能和 pull requests 的人

2,文档（The Docs）
项目中包含的常见文件
Readme请先读我: Readme 文件通常描述了项目如何使用、编译的细节，有时也提供参与项目方法

*Contributing贡献:*该文档详细描述了维护者希望看到补丁或功能实现的具体规范。这可能包含了如何编写测试，代码语法风格，或者补丁应用范围。

*License许可证:*LICENSE 文件就是项目的许可证

*文档和 Wikis（Documentation and Wikis）:*许多大型的项目没办法在一个 Readme 文件中描述所有的细节，这种情况下你可以在仓库中找到另一个文件的链接或者叫“docs”的文件夹

3,Issue 创建一个问题单

有关 Issues 的专业建议
检查当前已有的问题单是否与你的问题有关
请明确你的问题：期望的输出是什么，实际发生了什么？以及其他人如何重现你的问题，通过链接到示例的方式重现问题
包含你的系统环境的详细信息，比如使用什么浏览器，库或者操作系统及其版本。

Issues（问题单）是一种伟大的工作方式，它用于对项目进行跟踪、增强和排错。它们就像电子邮件一样 —— 除了它们可以与团队的其他成员进行分享和讨论。大多数软件项目都会有某种错误跟踪器，GitHub 的错误跟踪器称为“Issues”，并且在每个仓库中都有自己的 Issues 部分。


GitHub 的问题跟踪是很特别的。因为我们（GitHub）专注于协作，参考和优秀的文本格式，所以一个典型的 GitHub 问题应该像这样：

标题和描述概括了这个问题是关于什么的。
**彩色 Labels（标签）**可以帮助你对问题进行分类和过滤（就像电子邮件中的标签一样）。
**Milestone（里程碑）**就像一个问题单的容器。这对于将问题单与特定功能或项目阶段（例如 Weekly Sprint 9/5-9/16 或者 Shipping 1.0）进行关联非常有用。
**assignee（责任人）**负责在任何指定的时间解决相应的问题
**Comments（评论）**允许有权访问仓库的任何人对该问题进行回复。

修改或添加一个 milestone，assignee 和 labels。
a>Milestones（里程碑）
Milestones 是对应于项目，功能或时间段的问题组。
发布测试（Beta Launch）—— 在你发布项目的 Beta 版之前，包含你需要修复的 bug 文件。这样可以确保你不会漏掉什么。
十月冲刺（October Sprint）—— 记录你在十月份应该做的问题单文件。相当于一个工作清单，时刻提醒你应该重点完成哪些工作。
重新设计（Redesign）—— 记录与重新设计项目的问题单文件。这是一种收集灵感的好方法。

b>Labels（标签）
标签是组织不同类型问题单的好方法。每个问题可以包含任意数量的标签，你可以一次性过滤一个或多个标签

c>Assignees（责任人）
每个问题都可以有一个责任人 —— 一个人负责解决该问题的人。通过问题顶部的灰色栏，以同样的方式选择受责任人

**d>Notifications（通知）
Notifications（通知）是 GitHub 保持你的 Issues 最新状态的方式。你可以通过它们找到仓库中最新的问题单，或者仅仅知道某人需要你的输入来推进一个问题。
*两种方式可以接收通知：*通过电子邮件和通过浏览器

e>@mentions（@提及）
@memtions（@提及）是在 GitHub 的问题单中提及其他 GitHub 用户的方式。我们可以在任何问题的描述或评论中使用该功能，也可以通过 @username（@用户名）向另一个 GitHub 用户发送通知，这跟 twitter 中的 @memtions 功能很像。

f>References（参考）
通常情况下，issue 会依赖于其他 issues，或者至少与它们相关。如果你想将它们关联起来，可以通过输入 #issue编号 来引用相关的问题：

4，Pull Request
开启一个 pull request，项目的维护者（们）可以比较你的分支和当前的分支，并确定是否合并（pull in）你的更改。

六： GitHub 上进行项目开发
软件是 GitHub 的心脏 —— 而代码是软件的 DNA。

版本控制 —— GitHub 上面的所有东西都被保存到 Git 中，而 Git 是当前最好的版本控制系统。版本控制允许你随时尝试你的想法，在代码中做一些错误的改变而不会打乱你的最终产品。
将你的代码保持放置在一个地方 —— 无论你是工作在多台计算机之上还是仅仅想把一些旧的项目从你的计算机上拿掉，GitHub 都将是一个在线存储项目的绝佳之地。
协作 —— 一旦你的代码托管在 GitHub 之上，你可以邀请其他人来跟你一起开发代码。你只需要给他们发送一个链接就可以邀请他们来帮助你修补 bug 啦。

Git —— 版本控制工具，GitHub 是建立在 Git 之上的。
GitHub —— 公司以及软件的名字。我们开发了该软件和网站来帮助你以一种优雅的姿势完成与 Git 仓库之间的交互工作。
GitHub.com —— 你在线查看仓库的网站。
GitHub Desktop —— 一个可以让你安装在计算机上的应用程序，它可以帮助你将本地代码同步到 GitHub.com 上面。

1，GitHub Desktop
GitHub Desktop 是在 GitHub.com 上获取代码最简单的方法
Git 仓库都是基于提交（commit） —— 你的代码在某个时间点的快照。在你将代码推送到 GitHub.com 之前，你至少需要进行一次提交
公共仓库（Public repository）—— 任何人都可以看到的公共仓库，但你可以选择谁可以提交（做出更改）。在 GitHub.com 上，你可以免费创建任意数量的公共仓库。
私人仓库（Private repository）—— 默认情况下只有你可以查看的私人仓库。通过添加协作者，你可以选择谁可以查看和提交到该仓库。私人仓库需要你支付一笔费用给 GitHub.com。
发布版本存在两个地方
计算机上的本地存储库 —— 在没有网络连接的情况下，你可以使用 GitHub Desktop 在该仓库中工作。
GitHub.com 上的远程仓库 —— 你可以将 GitHub.com 上仓库的链接发送给别人，这样他们就可以看到你的代码，并使用 GitHub 的其他功能（如 Issues 管理和 Pull Requests）。

2， GitHub.com 上面获得代码
从 GitHub.com 上下载一些代码到你的计算机上或者在多台计算机之间同步更改，你将需要拉取更改或者克隆一个仓库
拉取更改（Pull changes）—— 点击 GitHub Desktop 右上角的“Sync”按钮，将代码从在线仓库（例如，你同时推送的更改）拉取到你的计算机上。注意：这个操作也会（往 GitHub.com）推送你还未曾推送的更改。
克隆一个仓库（Clone a repository）—— 点击 GitHub.com 上的“Clone in Desktop”按钮在你的计算机上创建该仓库的新副本。

七：Forking 项目
*Forking：*自己使用 GitHub 一段时间之后，你或许想要给其他人的项目贡献一些代码，或者从其他人现有的项目开始开发，这个过程称之为 forking
Forks 充当原始仓库和你的副本之间的桥梁。你可以通过对原始项目进行更改，并提交 Pull Requests 来帮他人优化他们的项目。Forking 是 GitHub 代码社交的核心。
1，Fork 指定仓库
在你 fork 到的 Spoon-Knife 中，找到导航右边栏的底部，然后单击“Clone in Desktop”按钮。当我们点击这个按钮时，它会咨询我们是否要启动 GitHub Desktop 应用程序来实现克隆仓库的操作，并选择保存仓库的位置。