学习git

学习了一上午大神廖雪峰写的git教程，特此记录以下
参考：https://www.liaoxuefeng.com/wiki/896043488029600

git config 查看配置信息

config 配置命令：git config
config 配置有system级别 global（用户级别）和local（当前仓库）三个设置先从system-》global-》local 底层配置会覆盖顶层配置分别使用--system/global/local 可以定位到配置文件
查看系统config:

git config --system --list

查看当前用户(global)配置

git config --global --list

查看当前仓库配置信息

git config --local --list
or
git config --local -l

初始化本地仓库

mkdir learngit
cd learngit
git init

git修改提交文件

提交修改文件到暂存区：git add readme.txt readme1.txt
提交修改到本地仓库：git commit -m "your modification description"
查看状态：git status
查看修改日志： git log
日志显示一行：git log --pretty=oneline
修改文件后，提交到暂存区之前查看修改内容：git diff readme.txt

如果git status告诉你有文件被修改过，用git diff可以查看修改内容

版本回退

回退到上一个版本：

$ git reset --hard HEAD^
HEAD is now at ef46b9f test diff

回退到下一个版本：
用git log命令找到id，

$ git reset --hard id

查看所有操作命令：

git reflog

利用此命令可以查看提交记录的id.

HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

工作区和暂存区

工作区（Working Directory）
就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区
版本库（Repository）
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

管理修改

查看工作区和版本库(暂存区)里面最新版本的区别:

git diff HEAD -- readme.txt

git commit只负责把暂存区的修改提交.
每次修改，如果不用git add到暂存区，那就不会加入到commit中.

撤销修改

如果修改了文件，还没有git add到暂存区
git checkout -- file可以丢弃工作区的修改
在修改文件后，git add之前可以用以下命令丢弃工作区的修改：

git checkout -- readme.txt

如果修改文件后，git add提交到了暂存区：
用命令git reset HEAD 可以把暂存区的修改撤销掉（unstage），重新放回工作区
用命令git checkout命令把工作区的修改撤销掉。

git reset HEAD readme.txt
git checkout -- readme.txt

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区
3. 如果文件修改后，git add提交了暂存区，并且git commit到版本库，可以用git reset --hard HEAD^回到上一版本

 git reset --hard HEAD^

删除文件

新增一个文件，git add,git commit.然后删除新增文件。

git add test.txt
git commit -m "add test.txt"
rm test.txt
git status

现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit

git rm test.txt
git commit -m "remove test.txt"

第二种情况：删错了文件，需要把误删的文件找回来：

git checkout -- test.txt

远程仓库

生成ssh key

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

在github中找到设置，添加ssh key,把本地目录中生成的id_rsa.pub内容复制到github中，保存。

添加远程仓库

新建仓库的情况：

echo "# learngit" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/riyuexing/learngit.git
git push -u origin master

添加本地现有仓库到远程仓库

git remote add origin https://github.com/riyuexing/learngit.git
git push -u origin master

复制其他仓库到新创建的仓库：

You can initialize this repository with code from a Subversion, Mercurial, or TFS project.
输入git 仓库地址:

从远程仓库克隆

要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。

Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。

分支管理

创建与合并分支

创建并切换到dev分支

git checkout -b dev

上一条命令相当于：

git branch dev
git checkout dev

查看当前分支：

git branch

修改readme.txt,然后提交

git add readme.txt
git commit -m "branch test"

切换到master分支

git checkout master

合并dev分支到master分支

git merge dev

删除dev分支

git branch -d dev

Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch

切换分支：git checkout

创建+切换分支：git checkout -b

合并某分支到当前分支：git merge

删除分支：git branch -d

解决冲突

创建新分支

git checkout -b feature1

修改readme.txt文件最后一行
Creating a new branch is quick AND simple.
提交修改

git add readme.txt
git commit -m "AND simple"

切换到master分支

git checkout master

在master分支上把readme.txt文件的最后一行改为：
Creating a new branch is quick & simple.
提交修改

git add readme.txt 
git commit -m "& simple"

现在git merge会出现冲突：
git merge feature1 果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件
我们可以直接查看readme.txt的内容：
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改最后一行如下后保存，并提交：
Creating a new branch is quick and simple.

git add readme.txt 
git commit -m "conflict fixed"

用带参数的git log可以看到分支的合并情况：

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

删除feature1分支

git branch -d feature1

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

首先，仍然创建并切换dev分支：

git checkout -b dev

修改readme.txt文件，并提交一个新的commit：
在readme.txt中添加一行：
merge branch with "--no--off".

git add readme.txt
git commit -m "add merge"

切换到master

git checkout master

合并dev分支

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

查看分支历史

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

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

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

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

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

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

Bug分支

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

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash(藏匿)功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

git stash

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

git checkout master
git checkout -b issue-101

现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后提交：

git add readme.txt
git commit -m "fix bug 101"

修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

git checkout master
git merge --no-ff -m "merge bug fix 101" issue-101

现在，是时候接着回到dev分支干活了！

git checkout dev
git status

工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

git stash list

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

git stash apply stash@{0}

Feature分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。

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

现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。

于是准备开发：

git checkout -b feature-starship

开发完成，提交

git add starship.txt
git commit "add starship feature"

切换到dev分支：

git checkout master

此时删除feature-starship分支，会失败：

git branch -d feature-starship

可以强行删除:

git branch -D feature-starship

开发一个新feature，最好新建一个分支；

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

多人协作

查看远程仓库的信息：

git remote

查看更加详细的信息：

git remote -v

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

推送分支

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

git push origin master

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

git push origin dev

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

master分支是主分支，因此要时刻与远程同步；

dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

抓取分支

git clone git@github.com:michaelliao/learngit.git

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。

git branch

如果想切换到远程dev分支

git checkout -b dev origin/dev

推送到远程dev分支：

git push origin dev

如果多人修改，推送到远程时会碰到冲突,推送失败，解决方法：先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

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

再pull:

git pull

这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：

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

首先，可以试图用git push origin 推送自己的修改；

如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

如果合并有冲突，则解决冲突，并在本地提交；

没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！

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

Rebase 变基(再学)

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

rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

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

tag比commit更好记，tag不能移动，commit能移动
tag跟摸一个commit绑定在一起

创建标签：

查看标签：git tag
给当前commit打标签： git tag v1.0
给某个commit打标签：
git log --pretty=oneline --abbrev-commit
找出commit id，再打标签
git tag v0.9 b455ad5

查看标签详情

git show v0.9

创建带有说明的标签

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

标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。

操作标签

本地删除，此时标签还未推送的远程仓库

git tag -d v0.1

推送标签到远程仓库：

git push origin v1.0
git push origin --tags

如果标签已经推送到远程仓库，先从本地删除

git tag -d v0.9

再删除远程的标签：

git push origin :refs/tags/v0.9

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

命令git push origin --tags可以推送全部未推送过的本地标签；

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

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

一个本地库关联多个远程仓库

关联一个远程仓库：

git remote add origin git@gitee.com:liaoxuefeng/learngit.git

之后就可以正常git push,git pull

删除已有的远程仓库

git remote rm origin

关联多个仓库

git remote add github git@github.com:michaelliao/learngit.git

git remote add gitee git@gitee.com:liaoxuefeng/learngit.git

push的时候：

git push github master
git push gitee master

自定义git

让Git显示颜色，会让命令输出看起来更醒目

git config --global color.ui true

忽略特殊文件

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。

好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

忽略文件的原则是：

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

在.gitignore文件中添加忽略的文件

# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

# My configurations:
db.ini
deploy_key_rsa

把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令是不是说working directory clean。

使用Windows系统要注意，如果你在资源管理器里新建一个.gitignore文件，它会提示你必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

有些时候，你想添加一个文件到Git，但发现添加不了，原因是这个文件被.gitignore忽略了
如果你确实想添加该文件，可以用-f强制添加到Git

git add -f App.class

或者你发现，可能是.gitignore写得有问题，需要找出来到底哪个规则写错了，可以用git check-ignore命令检查：

git check-ignore -v App.class