git学习：远程分支

下面是远程仓库的操作，不是远程分支

添加远程仓库

假如现在gitlab已经搭建完成，公钥已经添加，远程仓库地址：ssh://git@git.andblog.cn:2222/root/abc.git

如果在本地创建了一个工程，想要推送到远程仓库里面

git remote add <shortname> <url>

添加一个新的远程 Git 仓库，同时指定一个你可以轻松引用的简写，默认是origin，意思为使用字符串 origin来代替整个 URL ssh://git@git.andblog.cn:2222/root/abc.git

$git remote add origin ssh://git@git.andblog.cn:2222/root/abc.git

克隆

将远程仓库的内容克隆到本地目录，默认名字就是origin，同时在本地自动创建master分支，指向origin/master，克隆会将所有分支都克隆到本地

$git clone ssh://git@git.andblog.cn:2222/root/abc.git

查看远程仓库

$git remote 
origin
git remote show [remote-name]
$git remote show origin
* remote origin
  Fetch URL: ssh://git@git.andblog.cn:20000/root/git_test.git
  Push  URL: ssh://git@git.andblog.cn:20000/root/git_test.git
  HEAD branch: master
  Remote branches:
    iss53  tracked
    master tracked
    test2  tracked
  Local branches configured for 'git pull':
    master merges with remote master
    test2  merges with remote test2
  Local refs configured for 'git push':
    master pushes to master (up to date)
    test2  pushes to test2  (up to date)

从远程仓库中拉取    

拉取 origin 的仓库中有但你没有的信息，可以运行 git fetch origin

$ git fetch [remote-name]

推送到远程仓库

当你想分享你的项目时，必须将其推送到上游。 这个命令很简单：git push [remote-name] [branch-name]。 当你想要将 master 分支推送到 origin 服务器时（再次说明，克隆时通常会自动帮你设置好那两个名字），那么运行这个命令就可以将你所做的备份到服务器，这里的master可以为你想要推送到服务器的任何分支：

$ git push origin master

远程仓库的移除与重命名

如果想要重命名引用的名字可以运行 git remote rename 去修改一个远程仓库的简写名。 例如，想要将 pb 重命名为 paul，可以用 git remote rename 这样做：

$ git remote rename pb paul
$ git remote
origin
paul

值得注意的是这同样也会修改你的远程分支名字。 那些过去引用 pb/master 的现在会引用 paul/master。

如果因为一些原因想要移除一个远程仓库 – 你已经从服务器上搬走了或不再想使用某一个特定的镜像了，又或者某一个贡献者不再贡献了 – 可以使用 git remote rm ：

$ git remote rm paul
$ git remote
origin

=====================================================

下面是远程分支的操作，不是远程仓库

看一个例子。 假设你的网络里有一个在 git.ourcompany.com 的 Git 服务器。 如果你从这里克隆，Git 的 clone 命令会为你自动将其命名为 origin，拉取它的所有数据，创建一个指向它的 master 分支的指针，并且在本地将其命名为 origin/master。 Git 也会给你一个与 origin 的 master 分支在指向同一个地方的本地 master 分支，这样你就有工作的基础。

“origin” 是当你运行 git clone 时默认的远程仓库名字。 如果你运行 git clone -o booyah，那么你默认的远程分支名字将会是 booyah/master。

如果你在本地的 master 分支做了一些工作，然而在同一时间，其他人推送提交到 git.ourcompany.com 并更新了它的 master 分支，那么你的提交历史将向不同的方向前进。 也许，只要你不与 origin 服务器连接，你的 origin/master 指针就不会移动。

如果要同步你的工作，运行 git fetch origin 命令。 这个命令查找 “origin” 是哪一个服务器（在本例中，它是 git.ourcompany.com），从中抓取本地没有的数据，并且更新本地数据库，移动 origin/master 指针指向新的、更新后的位置。

然后将origin/master分支合并到本地的master分支，然后将本地的master分支推送到远程的服务器上面，注意：origin/master为只读，不能将本地的master分支合并到origin/master上面。

$ git push origin master  意思是将master分支推送到远程仓库origin中

推送

当你想要公开分享一个分支时，需要将其推送到有写入权限的远程仓库上。 本地的分支并不会自动与远程仓库同步 – 你必须显式地推送想要分享的分支。 这样，你就可以把不愿意分享的内容放到私人分支上，而将需要和别人协作的内容推送到公开分支。

默认是推送哪个分支，哪个分支才会被推送上去，而不是全部会推送。

如果希望和别人一起在名为 serverfix 的分支上工作，你可以像推送第一个分支那样推送它。 运行 git push (remote) (branch):

$ git push origin serverfix  意思是将serverfix分支推送到远程仓库origin中
Counting objects: 24, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done.
Total 24 (delta 2), reused 0 (delta 0)
To https://github.com/schacon/simplegit
 * [new branch]      serverfix -> serverfix

远程分支在本地操作

当master分支克隆到本地后，默认会在本地创建一个master分支，指向origin/master，用户可以直接在本地的master分支操作

* c750627 (origin/master, origin/HEAD, master)

但是当抓取到其他新的远程跟踪分支时，本地不会自动生成一份可编辑的副本（拷贝）。 换一句话说，这种情况下，不会有一个新的 serverfix 分支 – 只有一个不可以修改的 origin/serverfix 指针。

可以手动在远程分支上面创建一个本地分支，然后在本地分支上面操作，运行git checkout -b [branch] [remotename]/[branch]。 这是一个十分常用的操作

$ git checkout -b serverfix origin/serverfix

之后的如下，即远程分支，本地分支，head都指向这个版本

* 9c2da5d (HEAD, origin/serverfix, serverfix)

删除远程分支

假设你已经通过远程分支做完所有的工作了 – 也就是说你和你的协作者已经完成了一个特性并且将其合并到了远程仓库的 master 分支（或任何其他稳定代码分支）。 可以运行带有 –delete 选项的 git push 命令来删除一个远程分支。 如果想要从服务器上删除 serverfix 分支，运行下面的命令：

$ git push origin --delete serverfix
To https://github.com/schacon/simplegit
 - [deleted]         serverfix

基本上这个命令做的只是从服务器上移除这个指针。 Git 服务器通常会保留数据一段时间直到垃圾回收运行，所以如果不小心删除掉了，通常是很容易恢复的。

推送错误

如果不小心把不该提交的代码或者敏感的数据（如密码）提交到远程git服务器上，可以使用git reset回滚到上一个commit，并且commit history不留下任何痕迹。

具体做法：前提是该分支是不受保护的，即可以强推

# 1.通过找到想要退回到的commit_id
$ git log
# 2.本地回到上一个commit_id
$ git reset --hard <commit_id>
# 3.推送到服务器，一定要加 --force 参数
$ git push origin HEAD:master --force
如果不加--force参数提交不上去，服务器rejected.

删除远程仓库里面标签

git push origin --delete tag <tagname>

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

默认是推送哪个分支，哪个分支才会被推送上去，而不是全部会推送。

所以，团队合作的分支看起来就像这样： 

bug分支　　
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，
修复后，合并分支，然后将临时分支删除。

推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
$ git push origin master

如果要推送其他分支，比如dev，就改成：
$ git push origin dev

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

多人协作的工作模式通常是这样：

首先，可以试图用git push origin branch-name推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。

git pull 和 git fetch

git pull = git fetch + merge to local

先，你的每一个操作都是要指明【来源】和【目标】的，而对于 pull 来说，【目标】就是当前分支
其次，你得清楚 git 是有 tracking 的概念的，所谓 tracking 就是把【来源】和【目标】绑定在一起，节省一些操作是需要输入的参数。
那么，假设你的 master 和 develop 都是 tracking 了的，于是：
# 当你在 master 下
$ git pull
# 等于 fetch origin，然后 merge origin/master

# 当你在 develop 下
$ git pull
# 等于 fetch origin，然后 merge origin/develop


怎么知道 tracking 了没有
如果你曾经这么推过：git push -u origin master，那么你执行这条命令时所在的分支就已经 tracking to origin/master 了，-u 的用处就在这里
如果你记不清了：cat .git/config

–

–

–