Git基础

learn from: 廖雪峰的官方网站-Git教程

1. 创建版本库

• 进入到准备当作Project的目录下，执行git init，生成隐藏文件夹.git即创建成功。
• git add <file>：用来将file添加到暂存区Stage中。
• git commit -m "<some messages>"：用来将暂存区Stage中的修改内容提交到版本库Version中。

2. 版本控制

• git log：用来从最近到最远的commit日志。
  • git log --pretty=oneline：增加参数pretty，用来简洁输出commit日志。
• git reset --hard HEAD^：用来将版本库中的master分支退回到上一个版本。
• git reflog：显示所有记录的命令，可以用来回到任意版本 git reset --hard <commit_id>。
• 工作区、暂存区、版本库关系如下：

• git diff应用场景、管理修改。

• git reset HEAD <file>：用来将暂存区的修改回退到工作区。
• git checkout -- <file>：用来丢弃工作区的修改，即用版本库中的版本替换工作区的版本。

场景1：
当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令 "git checkout -- <file>"。
场景2：
当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步:
a) 第一步用命令 "git reset HEAD <file>";
b) 就回到了场景1，第二步按场景1操作。
场景3：
已经提交了不合适的修改到版本库时，想要撤销本次提交，
"git reset --hard <commit_id>"回到任意版本，不过前提是没有推送到远程库。

• 当删除了工作区的文件后，有两种情况：

  • 确实要删除文件

    • git rm <file>：用来删除版本库中的文件，要commit才行，实际可以理解为在暂存区记录了要删除版本库中文件的命令。
    • git commit -m "<some messages>"：用来提交删除到版本库中。
    • 注意：先手动删除文件，然后使用git rm 和git add效果是一样的。

  • 误删了文件要还原

    • git checkout -- <file>：用来将版本库中的文件覆盖工作区的文件

3. 远程仓库

• 先有本地库，后有远程库

1. 登陆GitHub，然后，在右上角找到”Create a new repo”按钮，创建一个新的仓库;
2. 在”Repository name”填入learngit，其他保持默认设置，点击”Create repository”按钮，就成功地创建了一个新的Git仓库;
3. 在GitHub上的这个learngit仓库还是空的，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库;
4. git remote add origin git@github.com:<your_github_username>/learngit.git,将工作区内容推到暂存区；如果出现”fatal: remote origin already exists”的问题，尝试先执行git remote rm origin后，再执行add;
5. git push -u origin master，将本地仓库推送到Github。
6. 查看一下Github中是不是已经有了本地的内容。

远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库

“-u”参数：表示把本地的master分支内容推送的远程新的master分支，并把本地的master分支和远程的master分支关联起来，以后的推送或者拉取时就可以简化命令

从现在起，只要本地作了提交，就可以通过命令：git push origin master, 把本地master分支的最新修改推送至GitHub。

• 先有远程库，后有本地库

1. git clone <repo_ssh_url>：用来克隆一个远程库到本地。
2. 在克隆的仓库中进行工作，然后add, commit, push这个流程就可以更新远程库了。

4. 分支管理

4.1 创建合并分支

• git branch：用于查看当前分支，会列出所有分支，当前分支前面有*。
• git branch <dev>：创建dev分支。
• git checkout <dev>：切换到dev分支。
• git checkout -b <dev>：git checkout命令加上-b参数表示创建并切换。
• git merge <dev>：用于合并dev分支到当前分支。
• git branch -d <dev>：用于删除dev分支。

4.2 解决冲突

当不同的分支都对同一个文件做了不同的修改以后，在master分支执行git merge <another_branch>会发生冲突， 这个时候可以通过git status可以告诉我们冲突的文件，之后通过git diff <file_name>查看不同分支修改的内容， 也可以直接打开<file_name>文件查看，其中Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容。

之后直接修改文件<file_name>决定如何合并，然后add，commit，就算合并结束了……

之后可以通过带参数的git log查看分支的合并情况：git log --graph --pretty=oneline --abbrev-commit， 结果类似下面的图形，不同的分支会用不同的颜色表示出来。

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/  
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL
* e475afc add distributed
* eaadf4e wrote a readme file

4.3 分支管理策略

合并分支的时候，Git会尽可能地使用Fast forward模式，这种模式下删除分支会丢失分支信息。

• 使用--no-ff参数强制禁用Fast forward模式 这个时候，Git就会在merge时生成一个新的commit，从分支历史上就可以看出分支信息。

例如：执行git merge --no-ff -m "merge with no-ff" dev后，使用git log --graph --pretty=oneline --abbrev-commit查看分支历史,

*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge
|/  
*   cf810e4 conflict fixed
...

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

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

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

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

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

4.4 Bug分支&feature分支

在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

修复Bug的具体流程如下：

1. git stash：保存dev分支的工作区现场，便于之后恢复现场继续开发工作；
2. 切换到带有Bug的那个分支，假设是master分支上有Bug，那么执行git checkout master切换到master分支；
3. 在master分支上执行git checkout -b issue-101创建并切换到新的分支issue-101，开始修复Bug；
4. Bug修复完成后执行git add <file>, git commit -m "<fixed bug 101>", 将修复提交；
5. git checkout master切换回master分支，git merge --no-ff -m "<merge bug fixed 101>" issue-101合并修复；
6. git branch -d issue-101删除issue-101分支；
7. git checkout dev切换到dev分支，继续之前的开发工作；
8. git stash list：用于列出之前保存的所有工作区现场；
9. 恢复工作区现场，一种可以用git stash apply <one_stash_id>，恢复后stash内容不删除，要用git stash drop <one_stash_id>进行手动删除；另一种用git stash pop，恢复的同时吧stash内容删除；

举例：

设A为游戏软件
1、master 上面发布的是A的1.0版本
2、dev 上开发的是A的2.0版本
3、这时，用户反映 1.0版本存在漏洞，有人利用这个漏洞开外挂
4、需要从dev切换到master去填这个漏洞，正常必须先提交dev目前的工作，才能切换。
5、而dev的工作还未完成，不想提交，所以先把dev的工作stash一下。然后切换到master
6、在master建立分支issue101并切换.
7、在issue101上修复漏洞。
8、修复后，在master上合并issue101
9、切回dev，恢复原本工作，继续工作。

添加一个新功能时，肯定不希望因为一些实验性质的代码，把master分支搞乱了，所以每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，删除该feature分支。

1. it checkout -b feature-vulcan：创建并切换到新的分支；
2. 开发新的功能……，git add <dev_files>, git commit -m "add feature vulan"；
3. git checkout dev，切换会dev分支，准备合并；
4. 之后和Bug分支的类似……
5. 假如由于某些原因，这个分支不允许合并要就地销毁了，执行git branch -d feature-vulcan会提示分支没有合并，如果删除，将丢失掉修改；
6. 执行git branch -D feature-vulcan进行强制删除。

4.5 多人协作

• git remote：用于查看远程库的信息；git remote -v：用于查看更详细的信息；
• git push origin master：把本地库当前分支的内容推送到远程库master分支；git push origin dev：把本地库当前分支的内容推送到远程库dev分支；

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
1. master分支是主分支，因此要时刻与远程同步；
2. dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
3. bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
4. feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

流程如下：

1. git clone <url>：克隆远程库的master分支；
2. git branch -b dev origin/dev：创建本地库dev分支，并和远程库dev分支链接起来；
3. 在本地库dev分支进行开发……
4. git push origin dev：试图将本地库dev分支的开发内容推送到远程库中；
5. 如果推送失败，则因为远程分支比本地库更新，需要先用git pull更新本地库内容，之后试图合并；
6. 如果合并有冲突，则解决冲突（上面详见4.2节），并在本地提交；
7. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功；
8. 如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>链接。

4.6 Rebase

没看懂，可以再看看下面这两个讲解。

• 廖雪峰的官方网站-分支管理-Rebase
• Git Book 中文版-rebase

5. 标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。

将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

5.1 创建标签

默认标签是打在最新提交的commit上的

1. 切换到要打标签的分支上：git checkout master；
2. git tag <name>：就可以打一个标签，默认打在HEAD指针上；
3. git tag：查看所有标签；
4. git tag <name> <commit_id>：对某一次提交打标签；
5. git show <name>：查看标签信息；
6. git tag -a <name> -m "<introduction_tag>" <commit_id>：创建带有说明的标签，用-a指定标签名，-m指定说明文字；

5.2 操作标签

1. git tag -d <name>：删除本地标签；
2. git push origin <name>：推送某个标签到远程库；
3. git push origin --tags：推送全部尚未推送到远程库的本地标签；
4. 删除远程库的标签要删除本地标签，之后git push origin :refs/tags/<name>删除远程库的标签；

5. 使用Github

1. 访问项目的主页，然后Fork这个项目；
2. 从自己的账户下克隆这个项目；
3. 对克隆的项目进行修改；
4. 在Github上发起pull request。

Bootstrap的官方仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap，以及你自己克隆到本地电脑的仓库，他们的关系就像下图显示的那样:

6. 自定义Git

6.1 忽略特征文件

有些时候必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件等等， 每次git status都会显示Untracked files …，有强迫症的童鞋心里肯定不爽； 好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件， 然后把要忽略的文件名填进去，Git就会自动忽略这些文件；

不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。 所有配置文件可以直接在线浏览：https://github.com/github/gitignore

忽略文件的原则是：

1. 忽略操作系统自动生成的文件，比如缩略图等；
2. 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
3. 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件;

• git add -f <file>：强制添加文件；
• git check-ignore：检查.gitignore文件的规则；
• git check-ignore -v App.class： Git会告诉我们.gitignore文件的哪一行规则忽略了该文件；

6.2 配置别名

--global：针对当前用户起作用的，如果不加，那只针对当前的仓库起作用；

• git config --global alias.st status：配置 git st 等价于 git status
• git config --global alias.co checkout：配置 git co 等价于 git checkout
• git config --global alias.ci commit：配置 git ci 等价于 git commit
• git config --global alias.br branch：配置 git br 等价于 git branch
• git config --global alias.unstage 'reset HEAD'：配置 git unstage 等价于 git reset HEAD
• git config --global alias.last 'log -1'：配置 git last 等价于 git log -l
• git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"：配置 git lg 等价于 git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

• 每个仓库的Git配置文件都放在.git/config文件中

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url = git@github.com:weiguozhao/learngit.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[alias]
    last = log -1

• 当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中

[alias]
    co = checkout
    ci = commit
    br = branch
    st = status
[user]
    name = your_name
    email = your@email.com

题外话

如果clone Github上面的仓库速度比较缓慢的话，可以尝试一下命令：

前提是有科学上网工具，并且使用Git的http进行clone，其中127.0.0.1后面是科学上网监听的端口，我的SSR是socker 1086。

• 加速：

  git config --global http.https://github.com.proxy socks5://127.0.0.1:1086
  git config --global https.https://github.com.proxy socks5://127.0.0.1:1086

• 删除：

  git config --global --unset https.https://github.com.proxy
  git config --global --unset http.https://github.com.proxy