关于git:深入浅出git六远端命令

后面的文章讲的命令都是操作本地仓库的, 我置信能够应酬大部分的开发情况, 提交代码到本地仓库曾经不是问题了, 那么这次咱们就来看看如何和近程仓库进行对接。

git clone — 克隆远端代码到本地

当咱们进行开发的时候，开发流程是这样的：首先将近程仓库 (地方仓库) 的代码 clone 到本地，在本地进行开发，开发实现之后将代码提交到近程仓库。

近程仓库并不简单, 实际上它们只是你的仓库在另外一台计算机上的拷贝, 咱们能够通过网络和这台计算机通信 – 也就是减少或是获取提交记录。咱们先通过命令将远端仓库 clone 到本地

git clone https://github.com/generalthink/git_learn.git

执行命令之后 git 仓库就从远端 clone 到本地了, 此时本地和远端的代码统一。执行了这个命令之后咱们本地有什么变动呢？
先查看咱们当初存在哪些分支

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

当咱们执行 git clone 的时候，Git 会为近程仓库中的每个分支在本地仓库中创立一个近程分支（比方 origin/master）。而后再 创立一个跟踪近程仓库中流动分支的本地分支，默认状况下这个本地分支会被命名为 master。

你可能留神到了咱们除了本地的 master 分支, 还多了 origin/master 的分支, 这种类型的分支就叫近程分支, 它反映了近程仓库在你上次和它通信的状态。还记得 index 那篇文章吗?index 文件中记录了工作目录, 暂存区, 本地仓库的版本用于跟踪文件状态, 那么近程仓库的状态由谁来保护呢? 没错就是这个 origin/master 分支。

须要留神的是近程分支有一个特地的属性, 当咱们检出时, 主动进入拆散 HEAD 状态(此种状态下提交并不能影响 origin/master 分支).git 这么做是出于不能间接在这些分支上进行操作的起因, 你必须在别的中央实现你的工作。

近程分支的命令标准是这样的:<remote name>/<branch name>, 当咱们应用 git clone 某个仓库的时候,git 曾经帮咱们把近程仓库的名称设置为 origin 了。

能够应用上面的命令来查看近程库对应的简短名称

$ git remote -v
origin  https://github.com/generalthink/git_learn.git (fetch)
origin  https://github.com/generalthink/git_learn.git (push)

下面咱们把远端仓库同步到了本地, 远端和本地的代码就是统一的了(本地仓库中两个分支都指向的最新的提交记录)。

分支跟踪

当咱们将本地 master 分支的代码 push 到近程的 master 分支 (同时会更新近程分支 origin/master) 的时候，咱们只须要执行 git push 就能够了，就如同 git 晓得咱们它们是关联起来的！

其实 master 和 origin/master 的关联关系是由分支的 ”remote tracking” 属性决定的，master 被设定为跟踪 origin/master — 示意 master 指定了推送的目的地以及拉取后合并的指标。

能够让任意分支跟踪 origin/master, 而后该分支会像 master 分支一样失去隐含的 push 目的地以及 merge 的指标。这意味着你能够在分支 bugFix 上执行 git push，将工作推送到近程仓库的 master 分支上。咱们能够通过上面的两种办法创立一个 bugFix 的分支，它跟踪近程分支 origin/master

• git checkout

  git checkout -b bugFix origin/master

• git branch

  须要保障 bugFix 分支曾经存在

  git branch -u origin/master bugFix
  
  如果以后就在 bugFix 分支上，命令能够优化成为
  
  git branch -u origin/master

这样 bugFix 就会跟踪 origin/master 了, 当咱们推送代码到远端的时候就能够不必指定目的地了，间接执行 git push 就能够将 bugFix 分支的代码推送到远端的 master 分支了。

通过 git branch -vv 命令能够查看本地分支关联的近程分支的对应关系

$ git branch -vv
* bugFix     215d0ff [origin/master] add bugFix.md
  foo        e2240d6 [origin/master: behind 2] add foo.md
  master     7b7adf6 [origin/master: behind 5] Revert "bugFix"
  newFeature 3136c72 [origin/master: behind 3] add test2.md

当你通过下面的命令设置了跟踪关系之后执行 git pull 的时候你可能会有这样的报错信息：

fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use
    git push origin HEAD:master
To push to the branch of the same name on the remote, use
    git push origin newFeature
To choose either option permanently, see push.default in 'git help config'.

这全是因为 git config push.default 设置，默认是 simple(从 git 2.0 开始)，这示意当本地分支和远端分支的名称不一样的时候 git 会回绝提交。为了让其容许 push 到它跟踪的分支，须要从新设置这个参数

git config --global push.default upstream

--global只扭转以后 git 仓库的配置。对于 push.default 有哪些值能够通过 git help config 命令查看。

设置实现之后，在执行 git push 命令就能够间接将 bugFix 分支的内容提交到 master 分支上了。

$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 327 bytes | 327.00 KiB/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/generalthink/git_learn.git
   e2240d6..215d0ff  bugFix -> master

开发流程

下面咱们的仓库曾经和远端统一之后，咱们就能够开发了，当初咱们要批改一个 bug, 做法就是本地新建一个 bugFix(命名标准各个公司是不一样的，个别配合 bts 工具)分支，
而后在这个分支下面批改，批改实现之后将批改提交到线上服务器，而后线上 jekins 会主动跑一些脚本，验证你提交的代码，或者检测抵触，有抵触就须要合并。等到所有没有问题之后就能够合并 master 去了，当然咱们本人开发是没有这么简单的，因而咱们就通过间接将 bugFix 分支的代码推送到远端 master 分支就能够了

提交代码到近程仓库

git push命令负责将咱们的变更上传到指定的近程仓库，当初间接将咱们的代码推送到近程分支

$ git push origin bugFix:master
To https://github.com/generalthink/git_learn.git
! [rejected]        bugFix -> master (fetch first)
error: failed to push some refs to 'https://github.com/generalthink/git_learn.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally。This is usually caused by another repository pushing
hint: to the same ref。You may want to first integrate the remote changes
hint: (e。g。, 'git pull。。。') before pushing again。hint: See the 'Note about fast-forwards' in 'git push --help' for details。

执行命令发现报错了，为什么会这样呢？是因为你在开发的过程中，你的共事也在开发，并且他开发的代码曾经合并到了骨干上，这个时候你本地的代码就不是最新的了, 这个时候如果你往远端 push 代码, 那么 git 就会给你抛出这个谬误提醒。

此时，远端和本地分支的状况是这样的。

能够看到远端 master 节点和本地的 origin/master 指向的并不是同一个 commit object, 而咱们执行的 git push 命令显然不能智能的帮忙咱们合并。此时咱们应该先同步远端更改到本地，合并这些批改，而后在 push 到骨干。

git fetch — 同步代码到本地

上面的命令用来和远端进行通信, 把远端的代码先同步到本地

git fetch origin master

git fetch 实现了仅有的然而特地重要的两步

**1. 从近程仓库下载本地仓库中缺失的提交记录 **
**2. 更新近程分支指针(如 origin/master)**

当初本地仓库的近程分支更新成了近程仓库相应分支最新的状态。它通常通过互联网 (http:// 或者 git:// 协定) 与近程仓库通信。
须要留神的是git fetch 并不会扭转你本地仓库的状态。它不会更新你的 master 分支，也不会批改你磁盘上的文件。

合并代码

当初咱们曾经获取到了近程的数据, 只须要将这些变动更新到咱们的工作目录中就能够了, 咱们只须要像合并本地分支那样来合并近程分支就能够了, 咱们能够通过以下三种形式来实现合并

1. git cherry-pick origin/master
2. git rebase origin/master
3. git merge origin/master

实际上，因为先抓取更新再合并到本地分支这个流程很罕用，因而 Git 提供了一个专门的命令来实现这两个操作。它就是咱们的 git pull。

git pull ===== git fetch;  git merge origin/master

git pull --rebase == git fetch;git rebase origin/master

当初本地的近程分支和近程仓库的代码放弃了统一, 咱们终于能够应用服务器 git push origin bugFix:master 提交咱们的代码了。

看着还挺不错, 当初咱们能够开心的应用 git 工作了, 然而须要记住的是 git push 之前肯定要保障要本地的近程指针肯定要和远端统一, 要不然你就只有等着报错吧。

近程命令语法

下面咱们看到了和近程仓库交互的命令次要有 git fetch/pull/push 这个三个, 有人常常应用的可能就只有 get pull,git push 这样的，可能第一次看到 git push orgin bugFix:master 这样的命令很惊奇，所以这里对这几个命令的语法做一些简介，如果有理解过的就能够不必看上面的文章了。

git push 语法

git push <remote> <localPlace:remotePlace>

例子：

git push origin master:master

示意切换到本地的 master 分支，获取所有提交，再到近程仓库 ”origin” 中找到 ”master” 分支 (如果没有会新建一个)，将近程仓库中没有的提交记录增加下来。
通过 ”localPlace” 参数来通知 git 提交记录来自 master，在推送到近程仓库中的 master, 前面的两个参数实际上是要同步的两个仓库的地位。
当只指定 localPlace 的时候 remotePlace 的值默认是咱们跟踪的分支名称(须要留神 push.default 参数的值), 如果以后分支就是你想要提交的分支，那么你能够间接写成git push

这里的 localPlace 和 remotePlace 依照官网阐明是一个 refspec，“refspec”是一个自造的词，意思是 git 能辨认的地位（比方分支 bugFix 或者 HEAD~1）。

git fetch

git fetch 和 git push 的参数及其相似，它们概念雷同，只是方向相同(因为你当初是下载，而非上传)

git fetch <remote> <remotePlace:localPlace>

举个例子

git fetch origin master

git 会到近程仓库的 master 分支上，而后获取所有本地不存在的提交，放到本地的 origin/master 上，留神 fetch 并不会更新本地的非近程分支，而是下载提交记录。

如果想要间接更新本地 master 分支也不是不能够，运行上面的命令即可

git fetch origin master:master

实践上是能够的，然而强烈建议不要那么做。

当咱们只执行 git fetch 不带任何参数的时候，它就会下载所有的提交记录到各个近程分支。

git pull

学会了 git fetch，那么 git pull 就很简略了,git pull 惟一关注的是提交最终合并到哪里。之前说过

git pull == git fetch;git merge

那么

git pull origin bugFix ====  git fetch orign master; git merge origin/bugFix

上图能够看到以后分支是 bugFix，执行 pull 命令之后 origin/master 的指向扭转了，bugFix 分支的内容和远端 master 分支的内容进行了合并，把这条命令拆解为 2 条来记忆我置信更容易让人了解。

总结

git 系列写到当初曾经完结了，总共写了 6 篇文章，三篇实践，三篇理论使用。实践是实战的根底，弄明确了实践了解起来更加容易，git 将再也不难，当然我也不可能将每个命令都进行粗疏的解说，
然而 2 - 8 实践在 git 中同样实用, 如果想看更加具体的命令，我置信官网文档才是最好的。