学习git

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

git config 查看配置信息
1. config 配置命令：git config
2. config 配置有system级别 global（用户级别）和local（当前仓库）三个设置先从system-》global-》local 底层配置会覆盖顶层配置分别使用--system/global/local 可以定位到配置文件
3. 查看系统config:
```
git config --system --list
```
1. 查看当前用户(global)配置
```
git config --global --list
```
1. 查看当前仓库配置信息
```
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.
1. HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
2. 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
3. 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
工作区和暂存区
1. 工作区（Working Directory）
  就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区
2. 版本库（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中.

撤销修改
1. 如果修改了文件，还没有git add到暂存区
  git checkout -- file可以丢弃工作区的修改
  在修改文件后，git add之前可以用以下命令丢弃工作区的修改：
```
git checkout -- readme.txt
```
1. 如果修改文件后，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中，保存。

添加远程仓库
1. 新建仓库的情况：
```
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
```
1. 添加本地现有仓库到远程仓库
```
git remote add origin https://github.com/riyuexing/learngit.git
git push -u origin master
```
1. 复制其他仓库到新创建的仓库：
```
You can initialize this repository with code from a Subversion, Mercurial, or TFS project.
输入git 仓库地址:
```
从远程仓库克隆

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

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

分支管理

创建与合并分支
1. 创建并切换到dev分支
```
git checkout -b dev
```
上一条命令相当于：
```
git branch dev
git checkout dev
```
查看当前分支：
```
git branch
```
1. 修改readme.txt,然后提交
```
git add readme.txt
git commit -m "branch test"
```
1. 切换到master分支
```
git checkout master
```
1. 合并dev分支到master分支
```
git merge dev
```
1. 删除dev分支
```
git branch -d dev
```
Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch

切换分支：git checkout

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

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

删除分支：git branch -d

解决冲突
1. 创建新分支
```
git checkout -b feature1
```
1. 修改readme.txt文件最后一行
  Creating a new branch is quick AND simple.
2. 提交修改
```
git add readme.txt
git commit -m "AND simple"
```
1. 切换到master分支
```
git checkout master
```
在master分支上把readme.txt文件的最后一行改为：
Creating a new branch is quick & simple.
提交修改
```
git add readme.txt 
git commit -m "& simple"
```
1. 现在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"
```
1. 用带参数的git log可以看到分支的合并情况：
```
git log --graph --pretty=oneline --abbrev-commit
```
1. 删除feature1分支
```
git branch -d feature1
```
分支管理策略

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

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
1. 首先，仍然创建并切换dev分支：
```
git checkout -b dev
```
1. 修改readme.txt文件，并提交一个新的commit：
  在readme.txt中添加一行：
  merge branch with "--no--off".
```
git add readme.txt
git commit -m "add merge"
```
1. 切换到master
```
git checkout master
```
1. 合并dev分支
```
git merge --no-ff -m "merge with no-ff" dev
```
1. 查看分支历史
```
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分支，那么在这两个分支上都可以看到这个标签。

操作标签
1. 本地删除，此时标签还未推送的远程仓库
```
git tag -d v0.1
```
1. 推送标签到远程仓库：
```
git push origin v1.0
git push origin --tags
```
1. 如果标签已经推送到远程仓库，先从本地删除
```
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/可以删除一个远程标签。

一个本地库关联多个远程仓库
1. 关联一个远程仓库：
```
git remote add origin git@gitee.com:liaoxuefeng/learngit.git
```
之后就可以正常git push,git pull
1. 删除已有的远程仓库
```
git remote rm origin
```
1. 关联多个仓库
```
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文件；
忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
1. 在.gitignore文件中添加忽略的文件
```
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

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

# My configurations:
db.ini
deploy_key_rsa
```
1. 把.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
```
相关阅读:
shell命令--stat
英文段子
 OCP读书笔记(16)
shell命令--uptime
OCP读书笔记(15)
shell命令--dmesg
OCP读书笔记(14)
shell命令--hostname
OCP读书笔记(13)
shell命令--uname
原文地址：https://www.cnblogs.com/AlexanderZhao/p/10911932.html

git config 查看配置信息

初始化本地仓库

git修改提交文件

版本回退

查看所有操作命令：

工作区和暂存区

管理修改

撤销修改

删除文件

远程仓库

添加远程仓库

从远程仓库克隆

分支管理

创建与合并分支

解决冲突

分支管理策略

Bug分支

Feature分支

多人协作

推送分支

抓取分支

Rebase 变基(再学)

标签管理

创建标签：

查看标签详情

创建带有说明的标签

操作标签

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

自定义git

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

忽略特殊文件