0，设置远程仓库的 url

git remote set-url origin <远程仓库的 url>

如果提示 No such remote ‘origin’ 则说明需要你添加一个远端名称（比如：origin）

git remote add origin <远程仓库的 url>

origin => 其实是别名（可以任意一个名字，这里只是跟随大流），代表你的远端仓库的名称。

啥是主机名？（不完全正确）

一般来说 origin 指的是你 clone 仓库到你本地时的一个别名。

如果你想推送到别人的仓库，就要添加一个新的主机别名才行。所以 origin 的用途就是这样了。

可以通过 git remote -v 查看主机名对应的 url

其中一个是 fetch 用的，还有一个是 upsteam 供 push 用的。

1，拉取远端分支到本地

首先你需要先把远端分支下载本地上

git fetch（简写：更新所有分支） 或 git fetch origin （看看是否有人新加了分支）

再查看目前仓库所有的分支

git branch -a

再执行以下命令即可将远程分支copy到新的分支上。

git checkout -b dev(本地分支名称) origin/develop(远程分支名称)

2，git pull 的原理

3，git rebase 的原理

假设都基于 A 节点创建新分支进行开发。

master 分支
A <- B 
 \
  C
feature 分支

rebase 到 master 会把 C 节点重新提交一个到 B 之后即：

feature 分支（rebase 后）
A <- B <- C1 
 \
  C
feature 分支

在日常工作中会不时的收到共享分支（如：master）更新的信息。即：

master 分支
A <- B <- D

A <- B <- C1 <- E
feature 分支

则 rebase 到 master 分支上是

master 分支
A <- B <- D

A <- B <- D <- C1 <- E
feature 分支

一句话总结：feature 分支最初的节点即：A （checkout出来的）后面的所有commit rebase 到指定分支上，都是在目标分支（master）后面重新逐个提交代码。
所以不建议feature有太多的提交，不然产生冲突你会很难受的。（又要重新一个一个去解决冲突）

建议可以把后期提交的commit用rebase合并成一个commit，当然在push的时候可能会报冲突。使用 force push即可。（切记，自能对自己的工作分支使用。）

4，git reset 和 revert 的区别

1，git revert 后会多出一条commit，这里可进行回撤操作。（把 head 指针向前移）
2，git reset 直接把之前 commit 删掉，非 git reset –hard 的操作是不会删掉修改代码（即：保留最新的代码），如果远程已经有之前代码，需要强推 git push -f （把 head 指针向回移）

小细节：revert commitID 是回到指定 commit 的上一个commit，而 reset 是回到指定的commit。

5，使用 git rebase 合并 commit

git rebase -i 你想合并 commit（518cd80） 的上一个 commit 。

i 是 interactive（互动） 的缩写。

// 这是上一个 commit （最旧的commit）
pick 518cd80 f1新功能
// 这是最新的 commit
pick d80f8e0 f1又有新功能

# Rebase 02f075e..d80f8e0 onto 02f075e (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]

这是会进入到 vim 编辑器中，将 commit（d80f8e0） 前的 pick 改成 squash（需要改commit信息） 或 fixup（直接跳过commit信息）。

当然，drop 也可以，但是容易触发到冲突。（个人猜测，是从 drop commit 的上一个 commit 再执行 rebase 从将 pick commit 重新提交一次）

6，tag 的作用

仅作标记

tag 对应某次 commit, 是一个点，是不可移动的。

//创建本地tag
git tag

//推送到远程仓库
git push origin

//本地 tag 的删除
git tag -d

7，什么是 non-fast-forward

那么什么是 fast-forward ？

例如：master 分支切出了新分支 feature 且 master 没有任何新的提交。

然后 master 合并 feature 分支只是将 head 指针指向 feature 最新的 commit 。这就是 fast-forward 。

在 graph 上看，这是没有任何合并的痕迹的。（呈一条直线）

而 non-fast-forward 则是多提交一个 commit 作为最新的提交。这样一来，从 graph 上看就有了合并的痕迹了。

8，删除本地和远端分支

本地：

git branch -d

远端：

git push origin –delete

9，关于文件大小写敏感的问题

由于 windows 系统是大小写不敏感（mac 我不知道，linux 是大小写敏感的），
导致修改文件名称可能无法提交。例如：a.js => A.js。

首先：git 默认是大小写不敏感的，想要提交修改名称后的文件，需要修改当前项目的 git 配置（妈的，这个配置不能项目共享！）

git config core.ignorecase false

接下来修改过名称的文件就可以的提交了。例如：a.js => A.js

提交过后，好像看起来什么问题。然后去到仓库的网站看，发现会有两个相同的文件
如： a.js（原先的文件） 和 A.js（修改名称后的文件）

但是我们本地的文件夹就只有一个修改后的文件呀（即：A.js）！

如果其它同事在此时拉下代码后会发现，文件名根本就没有改成功（所以就要快点执行下一步）

神奇的地方就在这里：

使用 git ls-files 查看，就会有刚才说的那两个文件了。

然后使用 git rm a.js 把原文件删掉，再 commit 一次即可。最后 stash 一次即可。因为最后还会有一个 A.js 保留，所以要用stash把 A.js 保留回去。

推送过后，你的同事把代码拉下来就能成功跟新文件名了。

---