Git 进阶篇

一. GitHub

1.1 简介

​ GitHub是全球最大的代码托管平台，开发人员可以将自己的代码免费发布在上面，供其他人学习使用，我们可以使用Git将我们本地的代码推送到GitHub上，接下来将为大家介绍如何在GitHub上建立仓库并将本地代码推送到GitHub上。

1.2 创建GitHub仓库并推送

1.2.1 在GitHub首页的左上角点击加号，然后点击"new repository"，出现如下图所示的界面：

1.2.2 创建完远程仓库后，出现如下界面：

1.2.3 按照图中所示，可以将本地库代码推送到GitHub上，如下图所示：

1.2.4会出现弹框，需要输入GitHub的用户名和密码

1.2.5接下来到GitHub上查看，如下图所示：

1.3 远程操作命令

• git remote add origin address: 添加远程地址，将origin作为远程地址的别名

• git remote set-url origin new_url: 改变origin的url地址。

• git push -u origin master:master: 将master分支推送到远程master分支，这是一个完整的写法；也可以简写git push，但是这种写法要求必须是在master分支，并且已经作过关联。

git pull origin master:my-test>: 将远程的master分支拉倒本地的my-test分支

git remote show: 查看所有的远程配置别名。

git remote show origin: 查看origin的详细信息。

*git branch -av 查看所有的分支，包括远程分支。

git clone address [new_name]: 将远程地址的项目克隆到本地，可以重命名为new_name.

git clone -b branch_name url: 将指定的分支克隆到本地

git pull url:将远程项目的增量拉取到本地，并且尽可能的去合并，其实相当于两个命令 git fetch + git merge.

1.4 远程非master分支操作

git push -u origin develop: 将本地的develop分支推**</font>送的远程的develop分支，并与之关联；操作完该命令后我们就可以在develop分支直接执行git push操作，就可以直接提交到develop分支。

例如：将如上提交的develop分支拉到本地的方式，并映射到本地的develop分支

git pull          #拉取远程的信息，会将远程的分支信息也会获取到
git branch -a     #查看所有的分支信息，而且会查看到远程的分支信息  
git checkout -b develop origin/develop  #创建新的分支develop，关联到origin/develop分支
git pull origin develop:develop   #上述的几个命令可以合并这一个命令

或者使用如下的方式，这也是新版的Git推荐的方式：

git pull
git branch -a
git checkout --track origin/develop

注意：如果本地分支的名字和远程分支不用的情况下可以使用第一种方式。

1.5 分支删除与重命名

注意 : 分支的重命名只能通过先删除远程分支然后在重新推送。

• git push origin :develop: 这是一种比较老的方式。

• git push origin --delete develop: 这是较为新的方式。

1.6 标签操作

• git tag v1.0: 创建名为v1.0的标签。

• git show v1.0: 查看v1.0标签的信息。

• git push origin v1.0: 将v1.0这个标签推送的远程。

• git push origin v1.0 v2.0: 将 v1.0 v2.0推送的远程。

• git push origin --tags: 将本地尚未推送的远程的标签都推送的远程。

• git pull: 如果有标签就把标签都拉下来。

二. git cherry-pick与git rebase

2.1 git cherry-pick

cherry-pick 中文翻译为精选，筛选。

• 在实际开发的过程中会碰到这样的场景，就是在某个分支A上做了很多次的提交，然而却发现有些事情应该是在另外一个分支B上实现的，针对这种情况就可以采用 git cherry-pick 来实现。

A. 如下图所示，master和develop分支都在处于同一个提交：

B. 接在在develop分支上做两次提交，如下图所示：

C. 将master分支内容切到develop分支的 83361929 这个提交，采用如下命令：

git checkout master          #切换到master分支
git cherry-pick 8336192942b  #将master分支内容达到develop分支的8336192942b这个提交

2.2 git rebase

git rebase在业内有两种翻译：“变基”或者“衍合”。叫什么名字其实都不重要，接下来看看git rebase的用法。
rebase与marge的比较可参考https://www.jianshu.com/p/9641717b076b

2.2.1 合并提交

• 在工作中我们会碰到这样的情况，就是一个很小的功能的添加或者修改都有很多次的提交，例如下图，都是在a.txt这个文件中添加内容，却做了很多次的提交

  
  

我们是否可以将最近的5次提交或者10次提交进行合并了，答案是可以的。

A. 执行如下命令：

git rebase -i HEAD~5  #以交互的方式合并最近5次提交

会出现如下界面：

• 接下来对一些常用参数作如下说明：

简写形式	全程	描述信息
p	pick	使用提交
r	reword	使用提交，但是修改提交的信息
s	squash	将此次提交合并到上一次提交，并使用提交信息
f	fixup	将此次提交合并到上一次提交，但是会丢弃提交信息
d	drop	将本次提交删除

B. 在出现的上图的文本中作如下的修改：

说明：意思是采用 0669efc 这次提交；将 95d639a 这个提交合并到 0669efc 提交一起，提交的信息也会合并；将 442d680 提交合并到上一次提交，但是会丢弃掉提交的信息；将 4a4aab4 提交信息进行修改；将 67fc57b 提交删除。

C. 最终的提交信息如下图所示

2.2.2 另外一种合并

在之前的课程中我们介绍过可以使用 git merge 的方式进行分支的合并，git rebase 也可以进行分值的合并，他们合并的区别在于 git merge 并不会改变历史提交，而 git rebase 会改变历史提交。但是 git rebase 会让整个提交历史看起来干净整洁。但是有些情况我们必须使用 git rebase ，在最后会给大家演示。

A. 如下图所示，在master和dev分支上分别有两个不同的提交

B. 在master分支上执行如下指令：

git rebase dev

说明：在rebase的过程中有冲突，我们需要手动的去解决冲突，然后执行如下指令接着执行

git add a.txt               # git add a.txt 表示确认修改完冲突
git rebase --continue       # 接着到下一个补丁，如果没有要解决的冲突就变基结束

C. 执行的结果如下图所示

2.2.3 其他指令

• git rebase --abort: 在变基的过程中随时中断变基。

• git rebase --continue: 接着变基，跳到下一个补丁。

2.2.4 必须要使用变基

​ 有这样一种场景，在github上创建了一个repository，并生成了README.md文件，而并没有拉取到本地版本库；接着在本地我们有创建了一个版本库，并执行了一系列的提交，此时无论是 push 或者 pull 均无法成功，此时必须要变基，命令如下：

git pull --rebase origin master

2.2.5 变基的注意事项

A. 尽量不要在主分支上执行变基。

B. 已经推送到远程版本库的代码不要执行变基。