一. 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. 已经推送到远程版本库的代码不要执行变基。
网友评论