Git学习笔记
一、 初始化仓库（init）
# 不想要 git 管理跟踪的文件,可以在仓库根目录添加 .gitignore 文件,在里面写对应的规则
$ git init 把当前目录初始化为 git 仓库
Initialized empty Git repository in D:/学习研究/正在进行/Git学习/learngit/.git/
二、添加文件到仓库（add，commit）
Git管理的文件分为：工作区，版本库，版本库又分为暂存区stage和暂存区分支master(仓库)。
工作区（Working Directory）： 比如我的learngit文件夹就是一个工作区
版本库（Repository）：工作区有一个隐藏目录.git，这个不算工作区，而是 Git 的版本库。Git 的版本库里存了很多东西，其中最重要的就是称为 stage（或者叫 index）的暂存区，还有 Git 为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
前面讲了我们把文件往 Git 版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建 Git 版本库时，Git 自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
更多工作区和暂存区的概念，工作区和暂存区 - 廖雪峰的官方网站 (liaoxuefeng.com)。
# 创建一个readme.txt文件，并将该文件提交到暂存区，然后提交到仓库
$ git add readme.txt # 告诉 Git，把文件添加到仓库
# 添加许多同种类型的文件,可以使用通配符 * (记得加引号) 如: git add "*.txt" 命令就是添加所有 .txt 文件
# 使用git add . 则会将当前的所有文件都添加到仓库
$ git commit -m "wrote a readme file" # 告诉 Git，把文件提交到仓库
[master (root-commit) 4309065] wrote a readme file
1 file changed, 2 insertions(+)
create mode 100644 readme.txt
$ git status # 查看仓库目前状态 (项目是否有修改、添加、未追踪的文件等)
On branch master
nothing to commit, working tree clean
三、 比较文件（diff）
-
git diff查看工作区和暂存区差异，
-
git diff --cached查看暂存区和仓库差异，
-
git diff HEAD 查看工作区和仓库的差异，
-
git add的反向命令git checkout，撤销工作区修改，即把暂存区最新版本转移到工作区，
-
git commit的反向命令git reset HEAD，就是把仓库最新版本转移到暂存区。
-
git diff 时是分为两种情况的：暂存区为空和暂存区不为空。
首先我们明确知道git diff是比较工作区和暂存区的文件的，如果此时暂存区为空，那么稍微有点不同，即：
-
暂存区为空使用git diff：因为此时暂存区为空，此时使用git diff同样也是比较工作区和仓库，即和使用git diff HEAD结果相同
-
暂存区不为空使用git diff:因为此时暂存区不为空，此时使用git diff比较的就是工作区和暂存区
讨论 - 廖雪峰的官方网站 (liaoxuefeng.com)
# 1. 修改文件某一文件之后，再查看仓库的状态
$ git status
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
# 2. 查看修改内容, 查看文件不同 (difference)
$ git diff
diff --git a/readme.txt b/readme.txt
index d8036c1..013b5bc 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
Git is free software.
\ No newline at end of file
# 3. 将修改后的文件添加到仓库
$ git add readme.txt
# 4. 查看当前状态
$ git status
On branch master
Changes to be committed:
(use "git restore --staged ..." to unstage)
modified: readme.txt
# 5. 提交到仓库
git commit -m "add distributed"
[master f06eedd] add distributed
1 file changed, 1 insertion(+), 1 deletion(-)
# 6. 再次查看当前仓库状态
$ git status
On branch master
nothing to commit, working tree clean
Changes to be committed：将要被提交的修改
四、提交记录和版本回退（log，reset）
HEAD 表示当前版本，也就是最新的提交
HEAD^ 上一个版本
HEAD^^ 上上一个版本
HEAD~100 往上100个版本
# 1. 查看版本提交记录
$ git log
commit ba9933f71761b488c284c5ddb9a2331276e4d7f8 (HEAD -> master)
Author: ********
Date: Mon Feb 21 12:47:00 2022 +0800
append GPL
commit f06eedd97fcbeff70c2a44bf79fe3eeedba97ff5
Author: ********
Date: Mon Feb 21 12:43:10 2022 +0800
add distributed
commit 430906517e1d196c45297edba787623e64acad9e
Author: ********
Date: Mon Feb 21 12:20:55 2022 +0800
wrote a readme file
# 2. 回退到上一个版本
$ git reset --hard HEAD^
HEAD is now at f06eedd add distributed
# 3. 再次查看版本提交记录
$ git log
commit f06eedd97fcbeff70c2a44bf79fe3eeedba97ff5 (HEAD -> master)
Author: ********
Date: Mon Feb 21 12:43:10 2022 +0800
add distributed
commit 430906517e1d196c45297edba787623e64acad9e
Author: ********
Date: Mon Feb 21 12:20:55 2022 +0800
wrote a readme file
最新的那个版本append GPL已经看不到了！好比你从 21 世纪坐时光穿梭机来到了 19 世纪，想再回去已经回不去了，肿么办？
-
如果命令行窗口还没有被关掉：你就可以顺着往上找啊找啊，找到那个
append GPL的commit id是1094adb...，于是就可以指定回到未来的某个版本：$ git reset --hard ba9933 HEAD is now at ba9933f append GPL -
如果命令行窗口被关掉了：在 Git 中，总是有后悔药可以吃的。当你用
$ git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的 commit id。Git 提供了一个命令git reflog用来记录你的每一次命令：$ git reflog f06eedd (HEAD -> master) HEAD@{0}: reset: moving to HEAD^ ba9933f HEAD@{1}: reset: moving to ba9933 f06eedd (HEAD -> master) HEAD@{2}: reset: moving to HEAD^ ba9933f HEAD@{3}: commit: append GPL f06eedd (HEAD -> master) HEAD@{4}: commit: add distributed 4309065 HEAD@{5}: commit (initial): wrote a readme file $ git reset --hard ba9933
五、撤销修改（checkout、reset）
-
撤销工作区中的修改
如果此时修改了文件，但是还没有提交到暂存区中。可以使用命令
git checkout -- file来撤销修改。# 1. 查看文件内容（在最后一段添加了一行文字） $ cat 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. My stupid boss still prefers SVN... # 2. 查看工作区状态 $ git status On branch master Changes not staged for commit: (use "git add..." to update what will be committed) (use "git restore ..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") # 3. 撤销工作区的修改 $ git checkout -- readme.txt # 4. 查看当前工作区状态 $ git status On branch master nothing to commit, working tree clean # 5. 查看撤销修改后的内容（此时回到了修改之前的内容） $ cat 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. -
撤销暂存区中的修改
如果此时修改了文件，并且提交到暂存区中了。可以使用命令
git reset HEAD来把暂存区的修改撤销掉（unstage），重新放回工作区。git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。# 1. 查看文件内容（在最后一段添加了一行文字） $ cat 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. My stupid boss still prefers SVN... # 2. 添加文件到暂存区 $ git add readme.txt # 3. 查看当前工作区状态 $ git status On branch master Changes to be committed: (use "git restore --staged..." to unstage) modified: readme.txt # 4. 撤销暂存区中的修改 $ git reset HEAD readme.txt Unstaged changes after reset: M readme.txt # 5. 查看当前工作区状态 $ git reset HEAD readme.txt Unstaged changes after reset: M readme.txt -
已经提交到版本库（仓库）中
使用上一章节的版本回退，可以回退到上一个版本，不过前提是没有推送到远程库。
六、删除文件（rm）
# 1. 添加一个新文件到暂存区
$ git add test.txt
# 2. 将暂存区的文件提交到版本库
$ git commit -m "add test.txt"
[master 160a0ae] add test.txt
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test.txt
# 3. 从工作区删除文件
$ rm test.txt
# 4. 查看当前状态
$ git status
On branch master
Changes not staged for commit:
(use "git add/rm ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
deleted: test.txt
no changes added to commit (use "git add" and/or "git commit -a")
# 5. 从版本库中删除该文件
$ git rm test.txt
rm 'test.txt'
# 6. 执行commit
$ git commit -m "remove test.txt"
[master 930e953] remove test.txt
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 test.txt
# 7. 查看当前状态
$ git status
On branch master
nothing to commit, working tree clean
小提示：先手动删除文件，然后使用git rm 和 git add效果是一样的。 注意：从来没有被添加到版本库就被删除的文件，是无法恢复的！
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
七、远程仓库（remote、push、clone）
在克隆或者推送仓库的时候可以选择SSH或者HTTPS协议，这两种方式的主要区别在于：
-
clone项目:使用ssh方式时，首先你必须是该项目的管理者或拥有者，并且需要配置个人的ssh key。而对于使用https方式来讲，就没有这些要求。
-
push:在使用ssh方式时，是不需要验证用户名和密码，如果你在配置ssh key时设置了密码，则仅需要验证配对密码。而对于使用https方式来讲，每次push都需要验证用户名和密码。
使用SSH方式
-
创建SSH Key。在用户主目录下，如果是windows路径在
C:\Users\Admin，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：$ ssh-keygen -t rsa -C "[email protected]"你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。如果一切顺利的话，可以在用户主目录里找到
.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。 -
登陆GitHub，点击头像，选择Settings——SSH and GPG keys，然后，点 “New SSH Key”，填上任意 Title，在 Key 文本框里粘贴
id_rsa.pub文件的内容，最终效果如下
1. 添加远程库
# 1. 查看远程地址
$ git remote -v
# 2. 添加远程地址
$ git remote add origin [email protected]:yiymou/learngit.git # 远程库的名字就是origin,是 Git 默认的叫法，也可以改成别的,
# 但是origin这个名字一看就知道是远程库。
# 3. 查看远程地址
$ git remote -v
origin [email protected]:yiymou/learngit.git (fetch)
origin [email protected]:yiymou/learngit.git (push)
# 4. push到远程仓库（origin）
$ git push -u origin master # 把当前分支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'.
# 5. 删除远程库地址
$ git remote rm origin
$ git push -u origin master中的-u参数是干嘛的？
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git 不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令，加了参数-u后，以后即可直接用git push 代替git push origin master。
2. 从远程克隆库
$ git clone [email protected]:yiymou/learngit.git
Cloning into 'learngit'...
remote: Enumerating objects: 28, done.
remote: Counting objects: 100% (28/28), done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 28 (delta 8), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (28/28), done.
Resolving deltas: 100% (8/8), done.
$ cd learngit/
$ ls
LICENSE.txt readme.txt test.txt
八、分支（branch、switch、checkout、merge）
分支管理 - 廖雪峰的官方网站 (liaoxuefeng.com)
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如 1.0 版本发布时，再把dev分支合并到master上，在master分支发布 1.0 版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
1. 创建并合并分支
分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了 50% 的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
如下图中圆圈表示的每一次的提交，每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
创建一个新的分支dev，并在dev分支中进行一次提交，然后再切换回到master分支，因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
# 1. 创建分支
$ git branch dev
# 2. 切换分支
$ git checkout dev
Switched to branch 'dev'
# 3. 创建并切换到新的分支（-b参数表示创建并切换，等同于上面两条命令结合。）
$ git checkout -b dev # 等同于命令git switch -c dev
Switched to a new branch 'dev'
# 4. 查看当前分支(当前分支前面会标一个*号)
$ git branch
# 5. 修改readme.txt文件
在最后一行添加
Creating a new branch is quick.
# 6. 在dev分支上正常提交
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+)
# 7. 切换回到master分支
$ git checkout master # 也可以使用命令git switch master
Switched to branch 'master'
# 8. 合并dev分支到当前分支（master分支）
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
# 9. 删除dev分支
$ git branch -d dev
Deleted branch dev (was 74c2f05).
# 10. 查看当前的分支（此时只剩下master分支）
$ git branch
* master
Fast-forward什么意思？
表示这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都能Fast-forward，后面还有其他的合并方式。
为什么要创建分支然后合并分支后又将分支删除？
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
2. 解决冲突
设想一下一下情况，创建一个分支feature1，在这个分支中修改readme文件并提交，然后回到分支master，此时同样修改readme文件并提交，现在，master分支和feature1分支各自都分别有新的提交，变成了这样：
**这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。**此时就需要我们手动解决冲突后再提交。
# 1. 创建并切换到分支feature1
$ git switch -c feature1
Switched to a new branch 'feature1'
# 2. 修改readme.txt最后一行，改为
Creating a new branch is quick AND simple.
# 3. 在feature1分支上提交
$ git add readme.txt
$ git commit -m "AND simple"
[feature1 f4ca0f9] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)
# 4. 切换到master分支
$ git switch master
Switched to branch 'master'
# 5. 在master分支上把readme.txt文件的最后一行改为
Creating a new branch is quick & simple.
# 6. 在master分支上提交
$ git add readme.txt
$ git commit -m "& simple"
[master afc8945] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
# 7. 这种情况下，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.
# 8. git status也可以告诉我们冲突的文件
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add ..." to mark resolution)
both modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
# 9. 查看readme.txt的内容（Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容）
$ cat 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.
My stupid boss still prefers SVN.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
# 10. 修改如下后保存
$ vim readme.txt
# 11. 在master分支上提交
$ git add readme.txt
$ git commit -m "conflict fixed"
[master 550cb7f] conflict fixed
# 11. 带参数git log可以看到分支的合并情况
$ git log --graph --pretty=oneline --abbrev-commit
* 550cb7f (HEAD -> master) conflict fixed
|\
| * f4ca0f9 (feature1) AND simple
* | afc8945 & simple
|/
* 74c2f05 branch test
* 5859117 (origin-github/master, origin-gitee/master) add test.txt
* 930e953 remove test.txt
* 160a0ae add test.txt
* d1b9a9c git tracks changes
* 50859fa git tracks changes
* 7fc353e git tracks changes
* c595fa0 git tracks changes
* cc7e8f4 understand how stage works
* f06eedd add distributed
* 4309065 wrote a readme file
# 12. 删除feature1分支
$ git branch -d feature1
Deleted branch feature1 (was 14096d0).
在上面的例子中，我的理解是，当有冲突的时候，使用git merge此时会合并不成功，并且处于等待解决冲突的状态，同时会在有冲突的文件中使用用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，下一次提交后，git就会默认现在已经修改了冲突并将两个分支合并（不管此时有没有真正解决冲突，只要再次提交，git就认为冲突已经解决）。
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用git log --graph命令可以看到分支合并图。
并非更改了同一个文件就会发生冲突。
3. 制禁用Fast forward模式（–no-ff方式的git merge）
通常，合并分支时，如果可能，Git 会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git 就会在 merge 时生成一个新的 commit，这样，从分支历史上就可以看出分支信息。
# 1. 创建并切换到分支dev
$ git switch -c dev
Switched to a new branch 'dev'
# 2. 在readme.txt最后一行增加
Creating a new branch is quick AND simple.
# 3. 在dev分支上提交
$ git commit -m "add a newline"
[dev f52c633] add merge
1 file changed, 1 insertion(+)
# 4. 切换回master
$ git switch master
Switched to branch 'master'
# 5. 使用--no-ff参数合并dev分支，表示禁用Fast forward
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
# 6. 用git log看看分支历史
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
...
因为在使用合并–no-ff参数合并dev分支时要创建一个新的 commit，所以加上-m参数，把 commit 描述写进去。不使用Fast forward模式，merge 后就像这样：
4. Bug分支（stash）
设想这样一个情况，如果我们有两个分支，分别是master、dev。如果此时正在dev分支上工作，并且此时的共作还没有完成，所以还没有提交到仓库。此时如果有一个非常紧急的bug需要修复，此时那此时需要从dev分支切换到master分支，那么问题来了，如果我们此时直接切换过去，当前dev工作区进行的修改将会丢失，并且由于当前共作没有完成，所以不希望此时进行提交，此时还有一种解决方法，就是通过stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作。
在此时我们先使用stash功能保存当前的工作现场，然后切换到master分支，开始进行bug的修复，创建并切换到issue-101分支，解决bug，然后回到master分支，将issue-101分支合并到master分支，此时就解决了bug，然后我们需要继续进行dev分支的工作，此时切换到dev分支，因为刚刚的bug是在master分支上解决的，此时的dev分支上相同的bug还没有被修复，此时我们可以先使用Git提供的cherry-pick命令，复制4c805e2 fix bug 101这个提交所做的修改，然后使用git stash pop，回到工作现场，继续进行工作。
# 1. 创建并切换到分支dev
$ git switch -c dev
Switched to a new branch 'dev'
# 2. 添加文件hello.py、修改文件readme.txt，查看当前状态
$ git status
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
# 3. 工作现场“储藏”起来
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
# 4. 切换到分支master，从master分支创建并切换到issue-101分支
$ git switch master
Switched to branch 'master'
$ git switch -c issue-101
Switched to a new branch 'issue-101'
# 5. 修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后提交
$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
# 5. 切换到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(-)
$ git branch -d issue-101
Deleted branch issue-101 (was 1057024).
# 6. 回到dev分支
$ git switch dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean
# 7. 使用cherry-pick复制4c805e2 fix bug 101这个提交所做的修改
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
# 8. 使用git stash pop恢复工作现场
$ git stash pop
Auto-merging readme.txt
On branch dev
Changes to be committed:
(use "git restore --staged ..." to unstage)
new file: hello.py
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: readme.txt
Dropped refs/stash@{0} (4e26ea25447ee003f180d78a72c054be3763545f)
# 8. 使用git stash list查看所有保存过的工作现场（由于之前仅有的一个工作现场被pop了，所以现在的工作现场为空）
$ git stash list
5. 多人协作
一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；- bug 分支只用于在本地修复 bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个 bug；
- feature 分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
总之，就是在 Git 中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！
多人协作的工作模式通常是这样：
- 首先，可以试图用
git push origin推送自己的修改； - 如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并； - 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin推送就能成功！
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to 。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
$ git remote # 查看远程库信息
$ git remote -v # 查看远程信息（包括地址）
$ git remote add origin [email protected]:yiymou/learngit.git # 添加远程库地址
$ git remote rm origin # 删除已关联的远程库 origin
$ git push -u origin master # 把当前分支master推送到远程仓库（第一次）
$ git push origin master # 把当前分支master推送到远程仓库
$ git push origin dev # 把当前分支dev推送到远程仓库
$ git clone [email protected]:yiymou/learngit.git # 从远程克隆库
$ git pull origin develop # 从远程(origin) 的 develop 分支拉取代码
$ git branch --set-upstream branch-name origin/branch-name # 建立本地分支和远程分支的关联
九、git多账号设置
# 1. 查看远程地址
$ git remote -v
# 2. 添加远程地址
$ git remote add origin-gitee [email protected]:yiymou/learngit.git
$ git remote add origin-github [email protected]:YIYMOU/learngit.git
# 3. 查看远程地址
$ git remote -v
origin-gitee [email protected]:yiymou/learngit.git (fetch)
origin-gitee [email protected]:yiymou/learngit.git (push)
origin-github [email protected]:YIYMOU/learngit.git (fetch)
origin-github [email protected]:YIYMOU/learngit.git (push)
# 4. 分别push到远程仓库
$ git push origin-gitee master
Enumerating objects: 28, done.
Counting objects: 100% (28/28), done.
Delta compression using up to 8 threads
Compressing objects: 100% (24/24), done.
Writing objects: 100% (28/28), 2.35 KiB | 481.00 KiB/s, done.
Total 28 (delta 8), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.2]
To gitee.com:yiymou/learngit.git
* [new branch] master -> master
十、常用命令查阅
# 1. 仓库配置和初始化仓库
$ git config --global user.name "Your Name" # 配置所有 Git 仓库的 用户名 和 email
$ git config --global user.email "[email protected]" # 配置所有 Git 仓库的 用户名 和 email
$ git config user.name "Your Name" # 配置当前 Git 仓库的 用户名 和 email
$ git config user.email "[email protected]" # 配置当前 Git 仓库的 用户名 和 email
$ git config --global user.name # 查看全局配置的 用户名 和 email
$ git config --global user.email # 查看全局配置的 用户名 和 email
$ git config user.name # 查看当前仓库配置的 用户名 和 email
$ git config user.email # 查看当前仓库配置的 用户名 和 email
$ git init # 把当前目录初始化为 git 仓库
# 2. 添加文件到仓库
$ git add readme.txt # 告诉 Git，把文件添加到仓库
$ git commit -m "wrote a readme file" # 告诉 Git，把文件提交到仓库
$ git status # 查看仓库目前状态 (项目是否有修改、添加、未追踪的文件等)
# 3. 比较文件
$ git diff # 查看修改内容, 查看文件不同 (difference)
$ git diff --cached
$ git diff HEAD --
# git diff 查看工作区(work dict)和暂存区(stage)的区别
# git diff --cached 查看暂存区(stage)和分支(master)的区别
# git diff HEAD -- 查看工作区和版本库里面最新版本的区别
如: git diff readme.txt 表示查看 readme.txt 修改了什么,有什么不同
# 4. 提交记录和版本回退
HEAD 表示当前版本，也就是最新的提交
HEAD^ 上一个版本
HEAD^^ 上上一个版本
HEAD~100 往上100个版本
$ git log # 查看提交记录
$ git log --graph # 查看分支合并图
$ git log --graph --pretty=oneline --abbrev-commit
$ git log --oneline #美化输出信息,每个记录显示为一行,显示 commit_id 前几位数
$ git log --pretty=oneline #美化输出信息,每个记录显示为一行,显示完整的 commit_id
$ git log --graph --pretty=format:'%h -%d %s (%cr)' --abbrev-commit --
$ git reset --hard HEAD^ # 回退到上一个版本
$ git reflog # 查看版本改变记录
$ git reset --hard # 通过commit_id来指定要回退的版本
# 5. 撤销修改
$ git checkout -- readme.txt # 撤销工作区的修改
$ git restore readme.txt # 撤销工作区的修改
$ git reset HEAD readme.txt # 撤销暂存区中的修改
$git resotre --worktree readme.txt # 从暂存区恢复工作区，
$git restore --staged readme.txt # 从master恢复暂存区
$git restore --source=HEAD --staged --worktree readme.txt # 从master同时恢复工作区和暂存区
# 6. 删除文件
$ rm test.txt # 从工作区中删除文件
$ git rm test.txt # 从版本库中删除文件
# 7. 远程仓库
$ git remote # 查看远程库信息
$ git remote -v # 查看远程地址
$ git remote add origin [email protected]:yiymou/learngit.git # 添加远程库地址
$ git remote rm origin # 删除已关联的远程库 origin
$ git push -u origin master # 把当前分支master推送到远程
$ git clone [email protected]:yiymou/learngit.git # 从远程克隆库
$ git pull origin develop # 从远程(origin) 的 develop 分支拉取代码
$ git branch # 查看分支
$ git branch dev # 创建分支dev
$ git checkout # 切换分支
$ git switch # 切换分支
$ git checkout -b # 创建+切换分支
$ git switch -c # 创建+切换分支
$ git merge # 合并某分支到当前分支
$ git merge --no-ff -m "merge with no-ff" dev # 合并 dev 分支到当前分支(禁用Fast forward 合并策略)
$ git branch -d # 删除分支
$ git branch -D dev # 强制删除 dev 分支
$ git stash # 保存当前工作区和暂存区的修改状态,切换到其他分支修复 bug 等工作,然后在回来继续工作
$ git stash list # 查看保存现场的列表
$ git stash pop # 恢复的同时把 stash 内容也删除
$ git stash apply # 恢复现场，stash内容并不删除
$ git stash drop # 删除 stash 内容
$ git stash apply stash@{0} # 多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash
$ git cherry-pick # 复制一个特定的提交到当前分支(当前分支的内容需要先 commit,然后冲突的文件需要解决冲突,然后 commit)
$ git rebase # 把本地未push的分叉提交历史整理成直线(使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比)
# 其他
$ git 查看 git 的相关命令 (git --help)
$ git --version 查看 git 的版本
$ git config 查看 git config 的相关命令
$ git config core.autocrlf # 查看core.autocrlf配置状态
$ git config --global core.autocrlf false # 配置core.autocrlf状态为false/input/true
# Linux通用命令
$ clear # 清屏
$ mkdir learngit # 创建目录
$ cd learngit # 改变目录
$ pwd # 用于显示当前目录
$ ls -ah # 查看当前目录下的文件,包含隐藏文件 (不带 -ah 看不了隐藏文件)
$ cat readme.txt # 查看文本文件
$ rm test.txt # 删除文件
十一、补充
所有的版本控制系统，其实只能跟踪文本文件的改动，比如 TXT 文件，网页，所有的程序代码等等，Git 也不例外。版本控制系统可以告诉你每次的改动，比如在第 5 行加了一个单词 “Linux”，在第 8 行删了一个单词 “Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从 100KB 改成了 120KB，但到底改了啥，版本控制系统不知道，也没法知道。
千万不要使用 Windows 自带的记事本编辑任何文本文件。原因是 Microsoft 开发记事本的团队使用了一个非常弱智的行为来保存 UTF-8 编码的文件，他们自作聪明地在每个文件开头添加了 0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个 “?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。建议你下载 Visual Studio Code 代替记事本，不但功能强大，而且免费！
为什么 Git 比其他版本控制系统设计得优秀，因为 Git 跟踪并管理的是修改，而非文件。
十二、常见问题
-
git add时遇到错误
warning: LF will be replaced by CRLF in test.txt. The file will have its original line endings in your working directory首先问题出在不同操作系统所使用的换行符是不一样的
Uinx/Linux采用换行符LF表示下一行（LF:LineFeed，中文意思是换行）；
Windows采用回车+换行CRLF表示下一行（CRLF:CarriageReturn LineFeed，中文意思是回车换行）；
Mac OS采用回车CR表示下一行（CR：CarriageReturn，中文意思是回车）。
假如你正在Windows上写程序，又或者你正在和其他人合作，他们在Windows上编程，而你却在其他系统上，在这些情况下，你可能会遇到行尾结束符问题。这是因为Windows使用回车和换行两个字符来结束一行，而Mac和Linux只使用换行一个字符。虽然这是小问题，但它会极大地扰乱跨平台协作。
使用命令查看配置状态
git config core.autocrlf得到的结果可能为input，true，false，分别表示
true add时git会把CRLF转换成LF false 保持不变 input add时git会把CRLF转换成为LF,签出时依旧为LF 可以参考该文章git warning: LF will be replaced by CRLF in XXXX.The file will have its original line endings in …_qi_sheng_的博客-CSDN博客
-
git push时遇到的错误
$ git push origin-gitee master The authenticity of host 'gitee.com (212.64.62.183)' can't be established. ED25519 key fingerprint is SHA256:+ULzij2u99B9eWYFTw1Q4ErYG/aepHLbu96PAUCoV88. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])?文件夹内少了一个known_hosts文件，本来密钥文件应该是三个，现在只有两个，便报了这样的错误，此时输入yes回车之后，生成了缺少了的known_hosts文件，便可解决这个问题。
-
删除分支时遇到的错误
$ git branch -d issue-101 error: The branch 'issue-101' is not fully merged. If you are sure you want to delete it, run 'git branch -D issue-101'.问题背景：现在我有三个分支，分别是 master、dev、issue-101。 在issue-101分支中进行了修改，然后切换到master分支，将issue-101合并到了master分支中，此时切换到dev分支，尝试在dev分支中删除issue-101分支，就会出先上面遇到的错误。
原因：将要删除的分支还没有合并到当前所在的分支。
解决方法：切换到master分支中，在master分支中删除issue-101分支，因为issue-101分支已经合并到了master分支中，所以可以进行删除。如果想要在dev分支中删除issue-101分支中，可以使用强制删除
git branch -D issue-101。
参考文献
Git教程 - 廖雪峰的官方网站 (liaoxuefeng.com)
git两种连接方式:ssh和http配置介绍 - 舞羊 - 博客园 (cnblogs.com)
Git：SSH、SSH与HTTP区别、git常用命令_Code farmer Aiden-CSDN博客_ssh和http
git warning: LF will be replaced by CRLF in XXXX.The file will have its original line endings in …_qi_sheng_的博客-CSDN博客