Git的配置
Git提供了一个叫做git config的工具，专门用来配置和读取相应的工作环境变量。
这些变量可以存放在以下三个不同的地方：
1./etc/gitconfig文件：系统中对所有用户都普遍适用的配置。若使用git config时用--system，读写的就是这个文件。
2.~/.gitconfig文件：用户目录下配置的文件只适用于当前用户。若使用git config时用--global，读写就是这个文件。
3.当前项目中的配置文件（也就是工作目录中的.git/config文件）：这里的配置仅对当前项目有效，每一级别的配置都会覆盖上层的相同配置。所以.git/config中的配置会覆盖/etc/gitconfig中的同名变量。
配置个人用户信息
配置个人的用户名称和email地址：
$ git config --global user.name "test"
$ git config --global user.email [email protected]
如果使用了--global选项，则修改的是当前用户目录下的配置文件~/.gitconfig，以后你的所有项目就会默认使用这里的用户信息。如果需要在特定的项目中使用其他的名字或者电邮，只要去掉--global重新配置即可，新的设定会保存在.git/config文件里。
查看配置信息
$ git config --list
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=d:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=true
core.fscache=true
core.symlinks=false
credential.helper=manager
user.name=yangengjienihao
[email protected]
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
user.name=wanjing
如果看到配置信息中有重复的变量名，则表明他们来自不同的配置文件，不过最终git实际采用的是最后一个。
Git创建仓库
git init
Git使用git init命令来初始化一个仓库，Git很多命令都需要在仓库中执行，所以git init是使用Git的第一个命令。在执行完git init命令后，Git仓库会生成一个.git目录，该目录包含了所有元数据。（不像svn会在每个子目录中都生成.svn目录，Git只在仓库的根目录生成.git目录）。
使用方法
使用当前目录作为Git仓库，我们只需使用它初始化
git init
该命令执行完毕后，会在当前目录下生成一个.git目录，使用我们指定的目录作为仓库。
删除这个.git目录即可删除仓库。
git clone
我们使用git clone 从现有的仓库中拷贝项目，类似于svn的check out
比如，要克隆 Ruby 语言的 Git 代码仓库 Grit，可以用下面的命令：
$ git clone git://github.com/schacon/grit.git
执行完这个命令后，会在当前目录下创建一个grit的目录，其中包含一个.git目录，用于保存下载下来所有的版本记录。如果要自己定义新建项目的名称，可以在上面的命令末尾指定新的名字：
$ git clone git://github.com/schacon/grit.git mygrit
Git基本操作
git add
git add命令将文件添加到缓存中，如下面我们添加两个文件
git add aa.txt bb.txt
git status
git status 用于查看上次提交之后是否有修改
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: aa.txt
new file: bb.txt
下面我们修改下aa.txt
$ vim aa.txt
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: aa.txt
new file: bb.txt
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: aa.txt
git diff
执行git diff来查看 执行 git status的结果的详细信息
git diff命令显示 已写入缓存 与 已修改但尚未写入缓存 的区别。git diff有两个主要的应用场景：
- 对比工作区(未 git add)和暂存区(git add 之后)：git diff
- 对比暂存区(git add 之后)和版本库(git commit 之后)：git diff --cached
- 对比工作区(未 git add)和版本库(git commit 之后)：git diff HEAD
git commit
使用 git add命令将快照的内容写入缓存中，而git commit命令将缓存区的内容添加到仓库中。
Git为你的每一个提交都记录你的名字和邮箱地址，所以第一步需要配置你的用户名和邮箱。
$ git config --global user.name 'test'
$ git config --global user.email [email protected]
接下来我们写入缓存，并提交对 hello.php 的所有改动。在首个例子中，我们使用 -m 选项以在命令行中提供提交注释。
$ git add hello.php
$ git status -s
A README
A hello.php
$ git commit -m '第一次版本提交'
[master (root-commit) d32cf1f] 第一次版本提交
2 files changed, 4 insertions(+)
create mode 100644 README
create mode 100644 hello.php
我们每次修改完文件内容后，都需要执行git add命令，然后再执行git commit -m “”，如果你感觉这样比较麻烦，我们可以直接执行指令 git commit -am “我修改了文件”，来省去add的操作。
git reset HEAD
命令git reset HEAD：取消已缓存的文件,比如我们修改了文件的内容并通过命令 git add aa.txt bb.txt将aa、bb修改的内容放入缓存区中，如果我们此时只想提交bb而不提交aa，此时我们就可以使用 git reset HEAD aa.txt将其移出缓存区了。
git rm
如果我们只是单纯的删除了本地文件，运行git status就会有Changes not staged for commit:的提示，此时就需要我们运行git rm
git rm
如果工作区和暂存区的内容不一致，使用git rm
git rm -f
如果文件只从工作暂存区中删除，工作区中不删除，就需要使用选项--cached
git rm --cached
如果我们通过使用 rm
git checkout --
因为版本库中还有，所以可以轻松的恢复文件，可是如果我们使用git rm
需要使用git reset --hard （commit id）
然后再 git checkout --
##还有一种方法
git restore --staged aa.txt //表示将暂存区的文件从暂存区撤出
git checkout -- aa.txt
git checkout其实就是用仓库中版本替换工作区中的版本，但是如果已经执行过git add后的内容是不能通过git checkout恢复的，需要使用git reset HEAD
git mv
git mv用于移动或重命名一个文件、目录、软连接
$ git mv README README.md
$ ls
README.md
版本的回退
想回退版本，首先我们要知道当前是什么版本，在Git中，HEAD就是当前版本，上一个版本就是HEAD^，上上一个版本就是HEAD^^，往上一百个版本就是HEAD~100。
现在我们要把当前版本回退到上一个版本，就需要使用命令git reset:
git reset --hard HEAD^
看看内容是不是上一个版本的内容了。
如果此时我们发现回退错了怎么办，只要能找到我们要回到的版本的commit id就行，然后使用：
git reset --hard 0c7cbdc1fdf2bec36462c306320449cd7dbfbc4e
就能回退到上面commit id对应的版本了。
现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？
在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：
$ git reflog
e475afc HEAD@{1}: reset: moving to HEAD^
1094adb (HEAD -> master) HEAD@{2}: commit: append GPL
e475afc HEAD@{3}: commit: add distributed
eaadf4e HEAD@{4}: commit (initial): wrote a readme file
在回退版本后，push到远程仓库时可能会失败：
$ git push origin dev
To github.com:yangengjie/CustomViewLearn.git
! [rejected] dev -> dev (non-fast-forward)
error: failed to push some refs to '[email protected]:yangengjie/CustomViewLearn.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
解决办法也很简单：使用-f 进行强制push即可
$ git push -f origin dev
Total 0 (delta 0), reused 0 (delta 0)
To github.com:yangengjie/CustomViewLearn.git
+ 5f52966...fde4535 dev -> dev (forced update)
远程仓库
现在的情景是，你已经在本地创建了一个Git仓库，又想在Github上创建一个Git仓库，并且让这两个仓库进行远程同步，这样Github上的仓库既可以作为备份，又可以让其他人通过该仓库进行协作。
-
步骤一：登录Github，然后找到“Create a new repository”创建一个新的仓库
image.png
在Repository name填入learngit，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库：
image.png
目前，在GitHub上的这个learngit仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。 - 步骤二：添加远程库
现在，我们根据GitHub的提示，在本地的learngit仓库下运行命令：
$ git remote add origin [email protected]:michaelliao/learngit.git
添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
- 步骤三：把本地库的所有内容推送到远程库上
$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git
* [new branch] master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
从现在起，只要本地作了提交，就可以通过命令：
$ git push origin master
把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！
从远程库clone
用命令git clone克隆一个本地库：
$ git clone [email protected]:michaelliao/gitskills.git
Cloning into 'gitskills'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.
Git分支管理
分支的创建
git branch (branchName)
分支的切换
git checkout (branchName)
//另外一个命令
git switch (branchName)
分支的创建并切换
git checkout -b (branchName)
//另外一个命令
git switch -c (branchName)
分支的查看
$ git branch
* dev
master
git branch查看所有分支，当前分支前面会标一个*号
然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：
Creating a new branch is quick.
切换到master分支，再查看下readme.txt，刚才添加的内容不见了，因为那个提交的是在分支dev上，而master分支此刻的提交点并没有变。
现在我们把dev上合并到master上。
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt发现和dev分支上的最新提交的内容完全一致。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并比较快。当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。
合并完成后，就能放心的删除dev分支了：
git branch -d dev
Deleted branch dev (was b17d20e).
冲突解决
准备新的分支 feature1，继续我们新分支的开发：
$ git switch -c feature1
Switched to a new branch 'feature1'
修改readme.txt最后一行，改为：
Creating a new branch is quick AND simple.
在feature1分支上提交：
$ git add readme.txt
$ git commit -m "AND simple"
[feature1 14096d0] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)
切换到master分支上：
$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。
在master分支上把readme.txt文件的最后一行改为：
Creating a new branch is quick & simple.
提交：
$ git add readme.txt
$ git commit -m "& simple"
[master 5dc6824] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
现在，master分支和feature1分支各自都分别有新的提交，变成了这样：
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。
我们可以直接查看readme.txt的内容：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：
Creating a new branch is quick and simple.
再提交：
$ git add readme.txt
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed
现在，master分支和feature1分支变成了下图所示：
最后，删除feature1分支：
$ git branch -d feature1
Deleted branch feature1 (was 14096d0).
禁止Fast forward
通常分支合并时，如果可能，Git会使用Fast forward模式，但是在这种模式下，删除分支会丢失分支信息。
我们可以使用--no-ff方式禁止Fast forward模式，在合并分支时就会生成一个新的commit。从分支历史上就能看到分支的信息。下面我们就来实战一下：
1.首先，创建并切换分支dev：
git switch -c dev
2.修改readme.txt并提交
git commit -am “add merge”
3.切回到主分支master
git switch master
4.准备合并分支（禁用 Fast forward模式）
git merge --no-ff -m "merge with no-ff" dev
因为禁用Fast forwar模式会生成一个新的commit 所以我们需要使用-m并把commit的描述写进去。
分支策略
在实际开发中，我们应该按照几个原则进行分支管理：
- 1.主分支master是稳定的，仅用来发布新版本，平时不在上面开发
- 2.平时开发都在dev分支上，在发布新版本时才合并到主分支上
-
3.开发成员都有自己分支，并时不时的往dev分支上进行合并
所以，团队合作的分支看起来就像这样：
image.png
Bug分支管理
比如我们在dev上进行开发，突然有个紧急的bug要修复，但是我们的工作估计还要一天才能完成，所以我们不能提交到dev分支上，幸好Git提供了一个stash的功能，可以把工作现场储存起来（如果可以提交就不要stash了），等以后恢复现场使用。
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：
$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git switch -c issue-101
Switched to a new branch 'issue-101'
现在修复bug，修复完成后提交到issue-101分支上，然后切换到master分支上，进行合并,最后删除issue-101分支：
$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
现在，是时候接着回到dev分支干活了！
$ git switch dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean
工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：
$ git stash list
stash@{0}: WIP on dev: f52c633 add merge
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
- 一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
- 另一种方式是用git stash pop，恢复的同时把stash内容也删了：
$ git stash pop
On branch dev
Changes to be committed:
(use "git reset HEAD ..." to unstage)
new file: hello.py
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: readme.txt
Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
再用git stash list查看，就看不到任何stash内容了：
$ git stash list
你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
$ git stash apply stash@{0}
另外需要注意的是：既然master分支上的代码有bug，那么dev分支上的代码也是有bug的，那么怎么修复呢？
Git提供了cherry-pick命令，让我们复制一个特定的提交到当前分支：
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。
多人协作
多人协作的流程（比如我们有主分支master和dev分支）：
- 1、通过命令git clone从远程仓库上克隆到本地。当你使用命令git branch查看分支时，会发现只有主分支master。
$ git branch
* master
要想在dev分支上开发，就需要创建远程origin的dev分支到本地，我们可以使用如下命令：
git switch -c dev origin/dev
现在就可以在dev分支上进行开发了，然后时不时的把dev分支push到远程上。
- 2、在dev分支上开发，并push到远程
$ git add env.txt
$ git commit -m "add env"
[dev 7a5e5dd] add env
1 file changed, 1 insertion(+)
create mode 100644 env.txt
$ git push origin dev
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
f52c633..7a5e5dd dev -> dev
如果你的小伙伴已经想origin/dev分支推送了他的提交，而碰巧你对同样的文件做了修改，并试图推送：
$ cat env.txt
env
$ git add env.txt
$ git commit -m "add new env"
[dev 7bd91f1] add new env
1 file changed, 1 insertion(+)
create mode 100644 env.txt
$ git push origin dev
To github.com:michaelliao/learngit.git
! [rejected] dev -> dev (non-fast-forward)
error: failed to push some refs to '[email protected]:michaelliao/learngit.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
推送失败，因为你的小伙伴最新的提交和你的提交是有冲突的，解决办法很简单：先用git pull把最新的提交从origin/dev抓下来，然后在本地合并，解决冲突，并推送：
$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/ dev
git pull失败了，原因是：没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置本地dev和远程origin/dev的链接：
$ git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
然后再pull。
$ git pull
Auto-merging env.txt
CONFLICT (add/add): Merge conflict in env.txt
Automatic merge failed; fix conflicts and then commit the result.
这回git pull成功，但是合并有冲突，需要手动解决。解决后，提交，再push：
$ git commit -m "fix env conflict"
[dev 57c53ab] fix env conflict
$ git push origin dev
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
7a5e5dd..57c53ab dev -> dev
因此，多人协作的工作模式通常是这样：
- 先使用命令git pull从远程上拉取。
- 然后进行开发，并时不时使用git push origin
推送到远程上。 - 如果推送失败，则因为远程分支比本地的更新，需要再次使用git pull从远程进行拉取，并进行合并，若有冲突解决冲突，解决完毕后使用git push origin
再次推送。
使用GitHub
如果我们想修改某个开源项目的bug或增加一个需求，改怎么办呢？
- 先Fork开源项目到自己的Github下
- 然后克隆自己Github下的开源项目到本地
- 对开源项目进行修改，然后提交到自己的仓库下
4.如果你希望开源项目能接受你的修改，可以在Github上发起一个pull request。对方是否接受就不一定了。
自定义Git
忽略特殊文件
- 在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。
# 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
有些时候，你想添加一个文件到Git，但发现添加不了，原因是这个文件被.gitignore忽略了：
$ git add App.class
The following paths are ignored by one of your .gitignore files:
App.class
Use -f if you really want to add them.
如果你确实想添加该文件，可以用-f强制添加到Git：
$ git add -f App.class
或者你发现，可能是.gitignore写得有问题，需要找出来到底哪个规则写错了，可以用git check-ignore命令检查：
$ git check-ignore -v App.class
.gitignore:3:*.class App.class
Git会告诉我们，.gitignore的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规则。