Git学习笔记

Git分布式版本控制系统

正确的版本控制系统使用方法是：一次提交只干一件事，或者完成一个新功能。

不要堆积好多事后再提交，那样的话就变成了文件备份系统。

参考资源：Git教程

基础操作

安装git：

sudo apt-get install git

安装完成后，还需要最后一步设置，在命令行输入：

 git config --global user.name "Your Name"

git config --global user.email "email@example.com"

创建空目录，把该目录变成git可以管理的仓库：

git init

当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的。

把一个文件放到本地Git仓库只需要两步：

第一步，用命令git add将文件放到暂存区：

git add readme.txt

第二步，用命令git commit告诉Git，把文件提交到仓库，-m后面输入的是本次提交的说明：

 git commit -m "wrote a readme file"

本地仓库命令详解

工作区>>>>暂存区>>>>仓库（版本库）

工作区： 就是一个多了.git文件的文件夹，不要想太多，就按Linux操作文件夹的方法正常操作

暂存区：

1. 存入暂存区 git add filename git rm filename 这两条都是修改暂存区
2. 递交暂存区 git commit -m “log” ，正常来说一般对暂存区修改以后一定要commit一下

版本库：git commit以后的最终版本存入地方，git最重要的一个地方，因为只有版本库的修改才可以跟踪

git add 就是把工作区的修改，提交到暂存区
git add的反向命令git checkout filename，撤销工作区修改，即把暂存区最新版本转移到工作区

git commit 把暂存区的修改，保存至本地仓库，提交到当前分支
git commit的反向命令git reset HEAD，就是把仓库最新版本转移到暂存区。
git push 把本地库的记录，推送至远程库

git status 查看当前git仓库*与上一次commit之后的仓库的一切修改，包括工作区的修改和暂存区的修改
git status会提示你下一步可能会做的事：
比如你对工作区做了修改，他可能会提示下一步要git add或者git checkout < filename >
刚执行完git add以后，git status跟踪的暂存区的修改，又会提示你下一步可能要提交git commit或者git reset HEAD < filename >

git diff filename 查看工作区和暂存区差异，主要是查看对工作区的修改
git diff --cached 查看暂存区和仓库差异，主要查看对暂存区的修改
git diff HEAD – filename查看工作区和仓库的差异，
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。

git只能跟踪文本文件的改动，没法跟踪文件的变化，Git跟踪并管理的是修改，而非文件。
比如操作：第一次修改 -> git add -> 第二次修改 -> git commit
当用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，
所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。

git log --pretty=oneline命令查看当前版本之前的commit日志记录，显示从最近到最远的提交日志。

 git log --graph --pretty=oneline --abbrev-commit

git reflog用来记录你的每一次命令，包括版本回退、版本提交的日志，以便确定要回到未来的哪个版本。

git rm filename用于从缓冲区和工作区中删除该文件。

远程仓库命令详解

关联本地库和远程库

本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

第1步：创建SSH Key。在用户主目录/home下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），输入命令创建SSH Key：

ssh-keygen -t rsa -C "youremail@example.com"

你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。

如果一切顺利的话，可以在用户主目录/home里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

第2步：登陆GitHub，打开“settings”，“SSH and GPG Keys”页面：

然后，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容，点“Add Key”，你就应该看到已经添加的Key

因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

从本地库到远程库

在GitHub创建新的远程仓库Create a new repository，命名为testgit，并将本地仓库与之关联，在本地仓库中使用命令：

git remote add origin git@github.com:GitHubName/testgit.git

把上面的GitHubName替换成自己的GitHub账户名

由于第一次创建github仓库，自动创建了README.md文件，需要先pull下来，同步本地仓库：

git pull origin master

再把本地库的所有内容推送到远程库上，用git push命令，实际上是把当前分支master推送到远程：

 git push -u origin master

由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来

此后，每次本地提交后，只要有必要，就可以使用命令推送最新修改：

git push origin master

从远程库到本地库

在远程库创建一个新仓库gitskills，使用命令git clone克隆一个本地库：

git clone git@github.com:GitHubName/gitskills.git

如果有多个人协作开发，那么每个人各自从远程克隆一份就可以了。

远程GitHub Issues作用：发现代码BUG，但是目前没有成型代码，需要讨论时使用，或者使用开源项目时候出现问题时使用
情景：A发现B的开源库，提交一个issue，B某天登录GitHub主页看到通知并与A进行交流解决问题，最后关闭issue

分支管理

分支作用

假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

利用分支即可解决该问题，你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

分支创建与合并

在Git里master分支是主分支，一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

git branch命令查看当前分支,当前分支前面会标一个*号

创建dev分支，然后切换到dev分支：

git checkout -b dev//相当于git branch dev +  git checkout dev

创建并切换到新的dev分支，可以使用（和上面的命令作用相同，但是更易理解）：

 git switch -c dev

直接切换到已有的master分支，可以使用：

git switch master

此时可以在dev分支上对readme.txt文件进行修改，正常提交到dev分支

git add readme.txt 

 git commit -m "branch test"

到此完成了dev分支工作，切换回master分支：

git checkout master

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！
因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：

最后将dev的工作结果合并到master分支上：

git merge dev

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

合并后即可放心删除dev分支：

git branch -d dev

最后使用git branch查看分支就仅剩下master分支了。

分支冲突解决

创建新的分支feature，在该分支进行readme.txt修改，然后在该分支上进行git add和git commit提交，切换到master分支，也对readme.txt文件进行修改（本次修改与feature的修改不同），然后同样在该分支进行git add和git commit提交，现在，master分支和feature分支各自都分别有新的提交，变成了这样：

Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突：

$ git merge feature
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

使用git status可以知道冲突的文件，可以cat查看该文件，git已经做了冲突标记，必须手动解决冲突后（对readme.txt重新编辑）再提交：

 git add readme.txt 

git commit -m "conflict fixed"

现在，master分支和feature分支变成了下图所示：

git log --graph --pretty=oneline --abbrev-commit 可以查看分支的合并情况，最后删除feature分支。

分支管理策略

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

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

开发人员每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

通常，合并分支时，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。例如：
准备将dev分支合并到master分支，请注意–no-ff参数，表示禁用Fast forward：

 git merge --no-ff -m "merge with no-ff" dev

可以看到，不使用Fast forward模式，merge后就像这样：

Bug分支管理

修复bug时，会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；
在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

git stash 保存工作进度，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作。
git stash list查看工作现场保存在什么地方。
git stash apply恢复工作进度，但是恢复后，stash内容并不删除，你需要用git stash drop来删除。
还可以用git stash pop恢复工作进度，恢复的同时把stash内容也删了。

Feature分支管理

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

如果要丢弃一个没有被合并过的分支，可以通过git branch -D 强行删除。例如：

git branch -D feature-vulcan

多人协作

查看远程库的信息：

 git remote -v//git remote

Git把master分支推送到远程库对应的远程分支上，把该分支上的所有本地提交推送到远程库：

 git push origin master/dev

多人协作的模式：

1. 首先，可以试图用git push origin 推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！

特别注意：
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，
用命令git branch --set-upstream-to origin/。
例如：

 git branch --set-upstream-to=origin/dev dev

变基Rebase

rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。

rebase操作可以把本地未push的分叉提交历史整理成直线；

操作步骤：

1. dev分支开发完毕后推送远程；
2. 切换master分支拉取远程；
3. 切换dev分支rebase到master分支

标签管理

发布版本时，先在版本库中打一个标签tag，标签是版本库的一个快照，是一个容易让人记住的名字，它跟某个commit绑定在一起。

命令git tag 用于新建一个标签，默认为HEAD，也可以指定一个commit id；

git tag v1.0

对commit id是f52c633的提交打标签：

git tag v0.9 f52c633

命令git tag -a -m "blablabla…"可以指定标签信息，用-a指定标签名，-m指定说明文字：

 git tag -a v0.1 -m "version 0.1 released" 1094adb

命令git tag可以查看所有标签。

命令git push origin 可以推送一个本地标签；

git push origin v1.0

一次性推送全部尚未推送到远程的本地标签：

git push origin --tags

命令git tag -d 删除一个本地标签

git tag -d v0.9

命令git push origin :refs/tags/删除一个远程标签

 git push origin :refs/tags/v0.9