Git 使用方法
上班第一天，主管和负责人都去开会了，没人管我就在垃圾桶旁边的工位摸了一早上鱼
感觉同事都很忙，并不是特别友善，但是问题不大
跟Swan吵架了，像一团缠一起的毛线解不开哎。。
下午收到了后面几天的培训安排，花了一点时间回忆了一下Git的使用方法，趁还没分配电脑，自己带的mac没电第一天没有加班，在楼下找自己的外卖找了半天😭
坐上了公交车，溜了溜了。。。
by the way，中大真大，在外面逛了一圈就算来过了叭
Git 使用方法
配置姓名和邮箱地址
$ git config --global user.name "Firstname Lastname" |
配置的结果会在~/.gitconfig中显示
[user] |
设置SSH Key
GitHub 上连接已有仓库时的认证，是通过使用了 SSH 的公开密钥认证方式进行的。创建公开密钥认证所需的SSH Key，并将其添加至 GitHub。已经创建过的用户，可以使用现有的密钥进行设置B。运行下面的命令创建SSH Key。
ssh-keygen -t rsa -C "your_email@example.com" |
输入密码后会出现以下结果:
Your identification has been saved in /Users/your_user_directory/.ssh/id_rsa. |
id_rsa 文件是私有密钥，id_rsa.pub 是公开密钥。
添加公开密钥
在 GitHub 中添加公开密钥，今后就可以用私有密钥进行认证了。
点击右上角的账户设定按钮（Account Settings），选择 SSH Keys 菜
单。点击 New SSH Key 之后，需要输入密钥名字，Key 部分请粘贴 id_rsa.pub 文件里的内容。
id_rsa.pub的内容可以用如下方法查看。
$ cat ~/.ssh/id_rsa.pub |
添加成功之后，创建账户时所用的邮箱会接到一封提示“公共密钥添加完成”的邮件。完成以上设置后，就可以用手中的私人密钥与 GitHub 进行认证和通信了。让我们来实际试一试。
创建新reposity
注意事项
Initialize this repository with a README
- Initialize this repository with a README 选项上打钩，随后GitHub 会自动初始化仓库并设置 README 文件，让用户可以立刻clone 这个仓库。如果想向 GitHub 添加手中已有的 Git 仓库，建议不要勾选，直接手动 push。
Add .gitignore
- 下方左侧的下拉菜单非常方便，通过它可以在初始化时自动生成 .gitignore 文件 A。这个设定会帮我们把不需要在 Git 仓库中进行版本管理的文件记录在 .gitignore 文件中，省去了每次根据框架进行设置的麻烦。下拉菜单中包含了主要的语言及框架，选择今后将要使用的即可。
提交
$ git add hello_world.php |
通过git add命令将文件加入暂存区 A，再通过 git commit命令提交。
添加成功后，可以通过 git log命令查看提交日志
$ git log |
进行 push
之后只要执行 push，GitHub 上的仓库就会被更新。
$ git push |
基本操作
$ mkdir git-tutorial |
如果初始化成功，执行了 git init命令的目录下就会生成 .git 目录。这个 .git 目录里存储着管理当前目录内容所需的仓库数据。在 Git 中，我们将这个目录的内容称为“附属于该仓库的工作树”。文件的编辑等操作在工作树中进行，然后记录到仓库中，以此管理文件的历史快照。如果想将文件恢复到原先的状态，可以从仓库中调取之前的快照，在工作树中打开。开发者可以通过这种方式获取以往的文件。
git status命令用于显示 Git 仓库的状态。
结果显示了我们当前正处于 master 分支下。
$ git status |
可以看到在 Untracked files 中显示了 README.md 文件。类似地，只要对 Git 的工作树或仓库进行操作，git status命令的显示结果就会发生变化。
git add——向暂存区中添加文件
如果只是用 Git 仓库的工作树创建了文件，那么该文件并不会被记入 Git 仓库的版本管理对象当中。因此我们用 git status命令查看README.md 文件时，它会显示在Untracked files里。
要想让文件成为 Git 仓库的管理对象，就需要用 git add命令将其加入暂存区（Stage 或者 Index）中。暂存区是提交之前的一个临时区域。
$ git add README.md |
将 README.md 文件加入暂存区后，git status命令的显示结果发生了变化。可以看到，README.md 文件显示在 Changes to be committed 中了。
git commit——保存仓库的历史记录
git commit命令可以将当前暂存区中的文件实际保存到仓库的历史记录中。通过这些记录，我们就可以在工作树中复原文件
记述一行提交信息
git commit -m "First commit" |
-m 参数后的 “First commit”称作提交信息，是对这个提交的概述。
记述详细提交信息刚才我们只简洁地记述了一行提交信息，如果想要记述得更加详细，请不加 - m，直接输入git commit命令。
新建一个hello world.py文件，git add “hello world.py”后直接输入git commit命令。执行后编辑器就会启动，并显示如下结果。
在编辑器中记述提交信息的格式如下。
- 第一行：用一行文字简述提交的更改内容
- 第二行：空行
- 第三行以后：记述更改的原因和详细内容
只要按照上面的格式输入，今后便可以通过确认日志的命令或工具看到这些记录。在以 #（井号）标为注释的 Changes to be committed（要提交的更改）栏中，可以查看本次提交中包含的文件。将提交信息按格式记述完毕后，请保存并关闭编辑器，以 #（井号）标为注释的行不必删除。随后，刚才记述的提交信息就会被提交。
git log——查看提交日志
commit 2a1448a6642c09cb662a56ddbb40aa477357b5b (HEAD -> master) |
如果只想让程序显示第一行简述信息，可以在git log命令后加上 –pretty=short。这样一来开发人员就能够更轻松地把握多个提交。
只显示指定目录、文件的日志
$ git log README.md |
显示文件的改动
如果想查看提交所带来的改动，可以加上 - p参数，文件的前后差别就会显示在提交信息之后。
$ git log -p |
查看某个文件的提交日志以及提交前后的差别。
$ git log -p filename |
git diff——查看更改前后的差别
我们在刚刚提交的 README.md 中写点东西。
diff --git a/README.md b/README.md |
由于我们尚未用 git add命令向暂存区添加任何东西，所以程序只会显示工作树与最新提交状态之间的差别
- “+”号标出的是新添加的行，被删除的行则用“-”号标出。我们可以看到，这次只添加了一行
用 git add命令将 README.md 文件加入暂存区。如果现在执行 git diff命令，由于工作树和暂存区的状态并无
差别，结果什么都不会显示。要查看与最新提交的差别，请执行以下命令。
$ git diff HEAD |
不妨养成这样一个好习惯：在执行 git commit命令之前先执行git diff HEAD命令，查看本次提交与上次提交之间有什么差别，等确认完毕后再进行提交。这里的 HEAD 是指向当前分支中最新一次提交的指针。由于我们刚刚确认过两个提交之间的差别，所以直接运行git commit命令。
$ git commit -m "Add index" |
保险起见，我们查看一下提交日志，确认提交是否成功。
$ git log |
成功查到了第二个提交
分支的操作
在进行多个并行作业时，我们会用到分支。在这类并行开发的过程中，往往同时存在多个最新代码状态。如下图所示，从 master 分支创建 feature-A 分支和 fix-B 分支后，每个分支中都拥有自己的最新代码。master 分支是 Git 默认创建的分支，因此基本上所有开发都是以这个分支为中心进行的。
不同分支中，可以同时进行完全不同的作业。等该分支的作业完成之后再与 master 分支合并。比如 feature-A 分支的作业结束后与 master合并，如下图所示。
git branch——显示分支一览表
git branch命令可以将分支名列表显示，同时可以确认当前所在分支。让我们来实际运行 git branch命令。
$ git branch |
可以看到 master 分支左侧标有“*”（星号），表示这是我们当前所在的分支。也就是说，我们正在 master 分支下进行开发。结果中没有显示其他分支名，表示本地仓库中只存在master一个分支。
git checkout -b——创建、切换分支
如果想以当前的 master 分支为基础创建新的分支，我们需要用到git checkout -b命令。
切换到 feature-A 分支并进行提交
执行下面的命令，创建名为 feature-A 的分支。
$ git checkout -b feature-A |
或者
$ git branch feature-A |
创建 feature-A 分支，并将当前分支切换为 feature-A 分支。这时再来查看分支列表，会显示我们处于 feature-A 分支下。
使用git branch可以看到feature-A 分支左侧标有“*”，表示当前分支为 feature-A。在这个状
态下像正常开发那样修改代码、执行 git add命令并进行提交的话，代码就会提交至 feature-A 分支。 像这样不断对一个分支（例如feature-A）进行提交的操作，我们称为“培育分支”。
在README.md文件中添加一行feature-A 这样一行字母，然后进行提交
$ git add README.md |
于是，这一行就添加到 feature-A 分支中
切换至master分支。查看README.md，发现文件内容并没有增加上面的那一行
特性分支
特性分支顾名思义，是集中实现单一特性（主题），除此之外不进
行任何作业的分支。在日常开发中，往往会创建数个特性分支，同时在
此之外再保留一个随时可以发布软件的稳定分支。稳定分支的角色通常
由 master 分支担当
之前我们创建了 feature-A 分支，这一分支主要实现 feature-A，除feature-A 的实现之外不进行任何作业。即便在开发过程中发现了 BUG，也需要再创建新的分支，在新分支中进行修正。基于特定主题的作业在特性分支中进行，主题完成后再与 master 分支合并。只要保持这样一个开发流程，就能保证 master 分支可以随时供人查看。这样一来，其他开发者也可以放心大胆地从 master 分支创建新的特性分支。
主干分支
主干分支是刚才我们讲解的特性分支的原点，同时也是合并的终点。通常人们会用master分支作为主干分支。主干分支中并没有开发到一半的代码，可以随时供他人查看。有时我们需要让这个主干分支总是配置在正式环境中，有时又需要
用标签 Tag 等创建版本信息，同时管理多个版本发布。拥有多个版本发布时，主干分支也有多个。
git merge——合并分支
们假设 feature-A 已经实现完毕，想要将它合并到主干分支 master 中。
✨首先切换到 master 分支
$ git checkout master |
然后合并 feature-A 分支。为了在历史记录中明确记录下本次分支合并，我们需要创建合并提交。因此，在合并时加上 –no-ff参数。
$ git merge --no-ff feature-A |
随后编辑器会启动，用于录入合并提交的信息。
默认信息中已经包含了是从 feature-A 分支合并过来的相关内容，所以可不必做任何更改。将编辑器中显示的内容保存，关闭编辑器即可。
git log –graph——以图表形式查看分支
git log –graph命令进行查看的话，能很清楚地看到特性分支（feature-A）提交的内容已被合并。除此以外，特性分支的创建以及合并也都清楚明了。
推荐阅读：