github使用
git基本操作
- 创建本地仓库
mkdir git-tutorial
cd git-tutorial
git init
git init命令会在当前目录创建一个.git目录，这个目录是git用来跟踪管理版本的，我们把这个目录叫做仓库。仓库里面的隐藏文件.gitignore用来配置git忽略哪些文件不需要跟踪。
- 之后查看查看仓库状态
git status
该命令用于查看仓库当前的状态，在操作过程中仓库的状态不断变化，我们可以通过该命令查看仓库当前的状态。
图片中结果显示的是当前处于master分支下
-像暂存区添加文件
git add
单纯的在仓库里创建修改文件并不会被记录到管理对象中，我们需要通过git add命令将文件添加到暂存区，暂存区中的文件才会被记录到管理对象中。暂存区时提交之前的一个临时区域
- 保存仓库历史记录
git commit
git commit命令用于保存仓库历史记录，每次提交都会生成一个唯一的commit id，我们可以通过该id来查看提交的历史记录。commit命令会打开默认编辑器，我们可以在编辑器中输入提交信息，也可以通过-m参数直接在命令行中输入提交信息。
-
- 终止提交：如果在编辑器启动了想终止提交那么将提交信息留空并直接关闭编辑器即可
-
查看提交日志
git log
git log命令用于查看提交日志，我们可以通过该命令查看提交的历史记录，包括提交人、提交时间、提交信息等。git log命令还有很多参数例如：git log 直接加目录名会显示该目录下的日志。git log -p 文件前后的差别就会显示在提交信息后。我们可以通过git log --help查看帮助信息。
- 查看更改前后的差别
git diff
查看当前工作树和暂存区的差别
-
分支的操作
从master分支创建feature-A和fix-B分支
分支操作结束后状态
-
显示分支一览表
git branch
带有星号(*)的分支表示当前所在的分支，我们可以通过git branch命令查看分支一览表。
- 创建切换分支
git checkout -b <name>
创建并转到<name>的分支等价于
git branch <name>
git checkout <name>
创建了分支且转换为新创建的分支对其进行编辑
切换到master分支后会发现<name>分支下的文件不见了，这是因为git checkout命令会切换到指定分支，同时会将工作树切换到指定分支的状态。我们可以通过git checkout命令切换分支，也可以通过git branch命令切换分支。
-
- 可以通过“-”参数切换到上一个分支
-
特性分支
Git 与 Subversion（SVN）等集中型版本管理系统不同，创建分支时
不需要连接中央仓库，所以能够相对轻松地创建分支。因此，当今大部
分工作流程中都用到了特性（Topic）分支。
特性分支顾名思义，是集中实现单一特性（主题），除此之外不进
行任何作业的分支。在日常开发中，往往会创建数个特性分支，同时在
此之外再保留一个随时可以发布软件的稳定分支。稳定分支的角色通常
由 master 分支担当。
之前我们创建了 feature-A 分支，这一分支主要实现 feature-A，除
feature-A 的实现之外不进行任何作业。即便在开发过程中发现了 BUG，
也需要再创建新的分支，在新分支中进行修正。基于特定主题的作业在特性分支中进行，主题完成后再与 master 分支合并。只要保持这样一个开发流程，就能保证 master 分支可以随时供
人查看。这样一来，其他开发者也可以放心大胆地从 master 分支创建新
的特性分支。 -
- 主干分支：主干分支是刚才我们讲解的特性分支的原点，同时也是合并的终
点。通常人们会用 master 分支作为主干分支。主干分支中并没有开发到
一半的代码，可以随时供他人查看。
有时我们需要让这个主干分支总是配置在正式环境中，有时又需要
用标签 Tag 等创建版本信息，同时管理多个版本发布。拥有多个版本发
布时，主干分支也有多个。
- 主干分支：主干分支是刚才我们讲解的特性分支的原点，同时也是合并的终
-
合并分支
git merge <name>
假设 feature-A 已经实现完毕，想要将它合并到主干分
支 master 中。首先切换到 master 分支
git checkout master
然后合并 feature-A 分支。为了在历史记录中明确记录下本次分支合
并，我们需要创建合并提交。因此，在合并时加上 --no-ff参数。
git merge --no-ff feature-A
合并完成后，我们可以通过 git log 命令查看历史记录
- 以图表形式查看分支合并情况
git log --graph
或者
git log --graph --oneline --all
效果如下
但是多个并行的分支合并到主干分支时，git并不会自动合并，而是将权力交给你，这时我们需要手动合并。手动合并时，我们需要先切换到主干分支，然后合并其他分支。为了在历史记录中明确记录下本次分支合并，我们需要创建合并提交。因此，在合并时加上 --no-ff参数。
-
更改提交的操作
-
回溯历史版本
git reset --hard <commit id>
我们可以通过git reset命令回溯历史版本，该命令会将当前分支的HEAD指针指向指定的commit id，同时会将工作树和暂存区切换到指定的commit id的状态。我们可以通过git reset --hard HEAD^命令回溯到上一个版本，也可以通过git reset --hard HEAD~3命令回溯到前3个版本。我们也可以通过git reset --hard <commit id>命令回溯到指定的版本。
此时再次创建一个fix-B分支，状态如下
- 推进至feature-A分支合并后的状态
git reflog
该命令会查看仓库执行过的操作的日志，我们可以通过该命令查看到回溯前的commit id，然后通过git reset --hard <commit id>命令回溯到指定的版本。
- 修改提交信息
git commit --amend
要修改上一条提交信息，可以使用 git commit --amend命令。
- 压缩历史
git rebase -i HEAD~2
该命令会将HEAD指针指向的commit id之前的2个commit id进行压缩，压缩后的提交信息会显示在文本编辑器中，我们可以通过修改文本编辑器中的提交信息来修改提交信息。修改成功后发现保留的分支哈希值改变，表示压缩成功。已经成为了一个新的提交
远程仓库
简述初始操作：可以先建立远程仓库再将本地仓库推送到远程仓库，也可以先建立本地仓库再将本地仓库推送到远程仓库。这里以先建立本地仓库再将本地仓库推送到远程仓库为例。
-
注意：先建立本地仓库再将本地仓库推送到远程仓库时，需要先在远程仓库建立一个空仓库，然后将本地仓库推送到远程仓库。期间不要初始化仓库
-
添加远程仓库
git remote add origin <url>
在 GitHub 上创建的仓库路径为“git@github.com:用户名/git-tutorial.git”。现在我们用 git remote add命令将它设置成本地仓库的远程仓库。
- 推送到远程仓库
git push -u origin master
该命令会将本地仓库的master分支推送到远程仓库的master分支。-u参数会将本地仓库的master分支与远程仓库的master分支关联起来，以后只需要使用git push命令就可以将本地仓库的master分支推送到远程仓库的master分支。
- 推送到master以外的分支
git push -u origin <branch name>
先在本地仓库中创建了 feature-D 分支，现在将它 push 给远程仓库并保持分支名称不变在远程仓库的 GitHub 页面就可以查看到 feature-D 分支了。
- 从远程仓库克隆
git clone <url>
该命令会将远程仓库克隆到本地仓库。克隆后的本地仓库会自动添加远程仓库的地址，我们可以通过git remote -v命令查看远程仓库的地址。
- 获取远程的分支
git checkout -b feature-D origin/feature-D
-
b 参数的后面是本地仓库中新建分支的名称。为了便于理解，我
们仍将其命名为 feature-D，让它与远程仓库的对应分支保持同名。新建
分支名称后面是获取来源的分支名称。例子中指定了 origin/feature-D，
就是说以名为 origin 的仓库（这里指 GitHub 端的仓库）的 feature-D 分
支为来源，在本地仓库中创建 feature-D 分支。 -
向本地的分支更改并推送
更改远程仓库已经拉取到本地了按本地仓库的操作即可
提交:
git push
从远程仓库获取 feature-D 分支，在本地仓库中提交更改，再将feature-D 分支推送回远程仓库，通过这一系列操作，就可以与其他开发者相互合作，共同培育 feature-D 分支，实现某些功能。
- 获取最新的远程仓库的分支
git pull origin feature-D
该命令会将远程仓库的feature-D分支拉取到本地仓库的feature-D分支。拉取后，我们可以通过git log命令查看本地仓库的feature-D分支的历史记录。GitHub 端远程仓库中的 feature-D 分支是最新状态，所以本地仓库中的 feature-D 分支就得到了更新。今后只需要像平常一样在本地进行提交再 push 给远程仓库，就可以与其他开发者同时在同一个分支中进行作业，不断给 feature-D 增加新功能。如果两人同时修改了同一部分的源代码，push 时就很容易发生冲突。所以多名开发者在同一个分支中进行作业时，为减少冲突情况的发生，建议更频繁地进行 push 和 pull 操作。