🚫本教程参照廖雪峰的官方网站 教程，请优先参考其网站。
Git优势 远程仓库 Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。完全可以自己搭建一台运行Git的服务器，不过现阶段，为了学Git先搭个服务器绝对是小题大作。好在这个世界上有个叫GitHub 的神奇的网站，从名字就可以看出，这个网站就是提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。
Github远程仓库 请直接去Github官网 注册一个账户。
Github SSH key设置 📌以下内容略写，请查阅相关其他资料
第1步：创建SSH Key。
第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面：然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容：
为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。
当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
Github仓库推送 按照Github提示执行指令将本地的仓库代码推送到Github，添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
1 2 3 git remote add origin git@github.com:Zhoufenmianfan/GitStudy.git git branch -M main git push -u origin main
1 2 3 4 5 6 7 8 9 10 11 12 $ git push -u origin main Enumerating objects: 20, done. Counting objects: 100% (20/20), done. Delta compression using up to 16 threads Compressing objects: 100% (17/17), done. Writing objects: 100% (20/20), 2.14 KiB | 2.14 MiB/s, done. Total 20 (delta 7), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (7/7), done. To github.com:Zhoufenmianfan/GitStudy.git * [new branch] main -> main branch 'main' set up to track 'origin/main'.
📌由于远程库是空的，我们第一次推送main分支时，加上了-u参数，Git不但会把本地的main分支内容推送的远程新的main分支，还会把本地的main分支和远程的main分支关联起来，在以后的推送或者拉取时就可以简化命令。
Github仓库绑定解除 想解除本地与远程仓库的连接，可以用git remote rm <name>命令。使用前，建议先用git remote -v查看远程库信息，这里的rm是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。
1 2 3 4 5 6 7 8 $ git remote -v origin git@github.com:Zhoufenmianfan/GitStudy.git (fetch) origin git@github.com:Zhoufenmianfan/GitStudy.git (push) $ git remote rm origin $ git remote -v
远程库克隆 假设我们从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。
1 2 3 4 5 6 7 8 9 $ git clone git@github.com:Zhoufenmianfan/Zhoufenmianfan.github.io.git Cloning into 'Zhoufenmianfan.github.io'... remote: Enumerating objects: 570, done. remote: Counting objects: 100% (569/569), done. remote: Compressing objects: 100% (187/187), done. remote: Total 570 (delta 241), reused 560 (delta 232), pack-reused 1 Receiving objects: 100% (570/570), 3.38 MiB | 1.99 MiB/s, done. Resolving deltas: 100% (241/241), done.
📌GitHub给出的地址不止一个，还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
分支管理 分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
分支操作 在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点。每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
分支创建 🧊使用命令git branch来创建一个分支，使用命令git checkout或者git switch可以切换到任意一个分支，或者使用合并的命令git checkout -b或者git switch -c来创建并切换到新创建的分支
🧊使用命令git branch还可以查看当前分支，git branch命令会列出所有分支，当前分支前面会标一个*号。
1 2 3 4 5 6 7 $ git checkout -b dev Switched to a new branch 'dev' $ git branch * dev main
在dev分支上正常提交，比如对readme.txt做个修改，加上一行内容再add再commit
1 2 3 4 5 6 7 8 9 10 11 12 13 $ git checkout dev Switched to branch 'dev' $ git add readme.txt $ git commit -m "add:new a branch dev" [dev 62d62a4] add:new a branch dev 1 file changed, 2 insertions(+), 1 deletion(-) $ git status On branch dev nothing to commit, working tree clean
分支切换 现在，dev分支的工作完成，我们就可以切换回main分支，由于一些特殊原因，Github提倡使用main分支名称，而不再使用master，因此现在已经没有master分支了，取而代之为main分支：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 $ git add readme.txt $ git commit -m "add:new a branch dev" [dev 62d62a4] add:new a branch dev 1 file changed, 2 insertions(+), 1 deletion(-) $ git status On branch dev nothing to commit, working tree clean $ git branch * dev main $ git checkout main Switched to branch 'main' $ git status On branch main nothing to commit, working tree clean
切换回main分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而main分支此刻的提交点并没有变：我们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支。
分支合并 🧊使用命令git merge用于合并指定分支到当前分支。现在，我们把dev分支的工作成果合并到master分支上，注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。
1 2 3 4 5 6 $ git merge dev Updating 241aeea..62d62a4 Fast-forward readme.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
分支删除 合并完成后，就可以放心地删除dev分支了：
1 2 3 4 5 6 $ git branch -d dev Deleted branch dev (was 62d62a4). $ git branch * main
分支冲突 首先看这样一种分支冲突情况：
第①步：一个分支为feature1分支，添加内容后add+commit；
1 2 3 4 5 6 7 8 9 10 11 12 $ git branch * main $ git switch -c feature1 Switched to a new branch 'feature1' $ git add readme.txt $ git commit -m "add:new a branch feature1" [feature1 19d592e] add:new a branch feature1 1 file changed, 3 insertions(+), 1 deletion(-)
第②步：切换到main分支，修改内容，add+commit；
1 2 3 4 5 6 7 8 9 $ git switch main Switched to branch 'main' $ git add readme.txt $ git commit -m "add:Step 7" [main 9be30e1] add:Step 7 1 file changed, 3 insertions(+), 1 deletion(-)
现在，main分支和feature1分支各自都分别有新的提交，变成了这样：
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 $ 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 status On branch main You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")
🧊使用命令git diff可以查看差异，++<<<<<<< ======= >>>>>>>用来区分不同的分支内容
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 $ git diff diff --cc readme.txt index 9c77a4d,214bcb7..0000000 --- a/readme.txt +++ b/readme.txt @@@ -6,4 -6,4 +6,8 @@@ step4：自定义修改文件内容，<E4> step5：🧊使用命令`git status`查看当前仓库内的文件和上一次commit操作后的文件差 异，提示在主分支`On branch master`被修改过了，`Changes not staged for commit:`但还没有准备提交的修改文件`modified: readme.txt`，推荐你使用命令`git add <file>`去将这个文件添加到pool中以备后续commit，或者使用命令`git restore <file>`去忽略这部分改动。`no changes added to commit`没有新的通过add文件到pool中去用于commit。 step6：创建一个新的分支dev - step7：直接在main上修改文件 -step7：创建一个新的分支feature1 ++<<<<<<< HEAD ++step7：直接在main上修改文件 ++======= ++step7：创建一个新的分支feature1 ++>>>>>>> feature1
观察抉择后，决定仍然使用main分支的内容，或者也可以主动观察feature1分支内容，对main进行修改后，再add+commit。
🧊使用命令git log --graph --pretty=oneline --abbrev-commit可以查看分支图日志
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 $ git add readme.txt (main|MERGING) $ git commit -m "conflick fixed" [main a86de26] conflick fixed $ git log --graph --pretty=oneline --abbrev-commit * a86de26 (HEAD -> main) conflick fixed |\ | * 19d592e (feature1) add:new a branch feature1 * | 9be30e1 add:Step 7 |/ * 62d62a4 add:new a branch dev * 241aeea addfile:cancel.txt * 9c6fad0 add:Step 5 * 674519f add:Step 4 * 6185ab1 add:Step 3; addfile:LICENSE * a71de4e add:Step 2 * 55fc0ac add:Step 1 $ git branch feature1 * main
现在，master分支和feature1分支变成了下图所示，如果不需要feature1分支了，就可以删除了。
1 2 3 4 5 6 $ git branch -d feature1 Deleted branch feature1 (was 19d592e). $ git branch * main
分支策略 通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
首先，仍然创建并切换deev分支，修改readme.txt文件，并提交一个新的commit，切换回main，准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward，因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。合并后，我们用git log看看分支历史。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 $ git switch -c deev Switched to a new branch 'deev' $ git add readme.txt $ git commit -m "add:merge feature1" [deev 7ff15b7] add:merge feature1 1 file changed, 2 insertions(+), 5 deletions(-) $ git switch main Switched to branch 'main' $ git merge --no-ff -m "merge with no-ff" deev Merge made by the 'ort' strategy. readme.txt | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) $ git log --graph --pretty=oneline --abbrev-commit * 9059eaa (HEAD -> main) merge with no-ff |\ | * 7ff15b7 (deev) add:merge feature1 |/ * a86de26 conflick fixed |\ | * 19d592e add:new a branch feature1 * | 9be30e1 add:Step 7 |/ * 62d62a4 add:new a branch dev * 241aeea addfile:cancel.txt * 9c6fad0 add:Step 5 * 674519f add:Step 4 * 6185ab1 add:Step 3; addfile:LICENSE * a71de4e add:Step 2 * 55fc0ac add:Step 1
可以看到，不使用Fast forward模式，merge后就像这样：
在实际开发中，我们应该按照几个基本原则进行分支管理：
所以，团队合作的分支看起来就像这样：
BUG分支 场景：软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 $ git status On branch main Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: readme.txt Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: readme.txt $ git diff diff --git a/readme.txt b/readme.txt index 3a7f95c..e7dfc56 100644 --- a/readme.txt +++ b/readme.txt @@ -8,5 +8,5 @@ step6：创建一个新的分支dev step7：创建一个新的分支feature1，想想垃圾，还是直接在main上修改文件 step8：分支管理 step9：工作的部分add到pool了 - +step10：工作了一部分，但是还没add到pool
🧊使用命令git stash将现在的工作区先存储起来。现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
1 2 3 4 5 6 7 $ git stash Saved working directory and index state WIP on main: 9059eaa merge with no-ff $ git status On branch main nothing to commit, working tree clean
首先确定要在哪个分支上修复bug，假定需要在main分支上修复，就从main创建临时分支：
1 2 3 $ git switch -c issue-101 Switched to a new branch 'issue-101'
然后修复了Bug，add+commit，再切换到main分支，并完成合并，最后删除issue-101分支：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 $ git add readme.txt $ git commit -m "delete:想想垃圾" [issue-101 bc2c1a8] delete:想想垃圾 1 file changed, 1 insertion(+), 1 deletion(-) $ git switch main Switched to branch 'main' $ git merge issue-101 Updating 9059eaa..bc2c1a8 Fast-forward readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -d issue-101 Deleted branch issue-101 (was bc2c1a8). $ git branch deev * main
想要继续干活，查看一下工作区状态，工作区是干净的，
🧊用git stash list命令查看，工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；另一种方式是用git stash pop，恢复的同时把stash内容也删了。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 $ git status On branch main nothing to commit, working tree clean $ git stash list stash@{0}: WIP on main: 9059eaa merge with no-ff $ git stash pop Auto-merging readme.txt On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") Dropped refs/stash@{0} (57e1c819b0b2264c33710b1f0ef9141c1a358305) $ git status On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")
同时我们发现，刚刚在开发时，我们一直在main分支上，并且在修bug前已经有一部分内容add到pool了，这时我们在修完bug后，commit提交的过程中，不只是把bug内容提交了，同样也把之前开发的add到pool中的内容也提交了，所以现在恢复的工作区的显示的status中只剩下了待add+commit的内容了。所以开发一定要记得在dev分支上！
再用git stash list查看，就看不到任何stash内容了，你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令git stash apply stash@{0}。
在main分支上修复了bug后，我们要想一想，dev分支是早期从main分支分出来的，所以，这个bug其实在当前dev分支上也存在。那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个main分支merge过来。
🧊使用命令git cherry-pick可以将指定的提交复制到当前分支上，这里由于我们是在main分支上开发的，所以已经不能直接复制bug那个提交了，我们复制了另一次切换分支前的提交。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 $ git cherry-pick 4c805e2 fatal: bad revision '4c805e2' $ git cherry-pick b99d80c Auto-merging readme.txt [deev ba2eadf] add:step10 Date: Thu Feb 29 22:49:00 2024 +0800 1 file changed, 2 insertions(+) $ git log --graph --pretty=oneline --abbrev-commit * ba2eadf (HEAD -> deev) add:step10 * 7ff15b7 add:merge feature1 * a86de26 conflick fixed |\ | * 19d592e add:new a branch feature1 * | 9be30e1 add:Step 7 |/ * 62d62a4 add:new a branch dev * 241aeea addfile:cancel.txt * 9c6fad0 add:Step 5 * 674519f add:Step 4 * 6185ab1 add:Step 3; addfile:LICENSE * a71de4e add:Step 2 * 55fc0ac add:Step 1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 $ git switch main Switched to branch 'main' $ git log --graph --pretty=oneline --abbrev-commit * b99d80c (HEAD -> main) add:step10 * bc2c1a8 delete:想想垃圾 * 9059eaa merge with no-ff |\ | * 7ff15b7 add:merge feature1 |/ * a86de26 conflick fixed |\ | * 19d592e add:new a branch feature1 * | 9be30e1 add:Step 7 |/ * 62d62a4 add:new a branch dev * 241aeea addfile:cancel.txt * 9c6fad0 add:Step 5 * 674519f add:Step 4 * 6185ab1 add:Step 3; addfile:LICENSE * a71de4e add:Step 2 * 55fc0ac add:Step 1
既然可以在main分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在main分支上“重放”行不行？当然可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到main分支。
功能分支 添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。于是和bug分支一样，不过是issue是main的分支，而feature是dev的分支。一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。
但是如果还没有合并到dev分支上，就需要停止开发，就需要强行删除feature分支。如果直接删除则会销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。
🧊使用命令git branch -D来强行删除分支
多人协作 当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
🧊使用命令git remote查看远程库的信息，或者，用git remote -v显示更详细的信息，上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。
1 2 3 4 $ git remote -v origin git@github.com:Zhoufenmianfan/Zhoufenmianfan.github.io.git (fetch) origin git@github.com:Zhoufenmianfan/Zhoufenmianfan.github.io.git (push)
推送分支 🧊使用命令git push来推送指定分支到有权限的关联远程库，推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上，如果要推送其他分支，比如dev，就改成：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 $ git push origin deev Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 16 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 369 bytes | 369.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (2/2), completed with 2 local objects. remote: remote: Create a pull request for 'deev' on GitHub by visiting: remote: https://github.com/Zhoufenmianfan/GitStudy/pull/new/deev remote: To github.com:Zhoufenmianfan/GitStudy.git * [new branch] deev -> deev $ git push origin main Enumerating objects: 24, done. Counting objects: 100% (24/24), done. Delta compression using up to 16 threads Compressing objects: 100% (22/22), done. Writing objects: 100% (22/22), 2.04 KiB | 2.04 MiB/s, done. Total 22 (delta 16), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (16/16), completed with 2 local objects. To github.com:Zhoufenmianfan/GitStudy.git 241aeea..b99d80c main -> main
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！
多人协作的工作模式通常是这样：
首先，可以试图用git push origin <branch-name>推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！
抓取分支 多人协作时，大家都会往master和dev分支上推送各自的修改。现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆。默认情况下，你的小伙伴只能看到本地的master分支。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 $ git clone git@github.com:Zhoufenmianfan/GitStudy.git Cloning into 'GitStudy'... remote: Enumerating objects: 42, done. remote: Counting objects: 100% (42/42), done. remote: Compressing objects: 100% (16/16), done. Receiving objects: 100% (42/42), 4.02 KiB | 4.02 MiB/s, done. remote: Total 42 (delta 23), reused 42 (delta 23), pack-reused 0 Resolving deltas: 100% (23/23), done. $ cd GitStudy/ $ git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean $ git branch * main
如果远程重新创建了一个分支，那么需要使用pull命令重新拉取一遍远程库的内容
1 2 3 4 5 6 7 8 9 10 $ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (1/1), done. remote: Total 3 (delta 2), reused 3 (delta 2), pack-reused 0 Unpacking objects: 100% (3/3), 349 bytes | 0 bytes/s, done. From github.com:Zhoufenmianfan/GitStudy * [new branch] deev -> origin/deev Already up to date.
🧊使用命令git checkout -b <本地分支> <远程分支>可以将远程分支创建到本地
1 2 3 4 5 6 7 8 9 10 $ git branch * main $ git checkout -b deev origin/deev Switched to a new branch 'deev' branch 'deev' set up to track 'origin/deev'. $ git branch * deev main
小伙伴开发了一下功能，add+commit到他本地的deev后，push到了我们共同的远程库
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 $ git branch * deev main $ git add readme.txt $ git commit -m "add:add a feature:step11" [deev 610e6ac] add:add a feature:step11 1 file changed, 2 insertions(+), 1 deletion(-) $ git push origin deev Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 16 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 379 bytes | 379.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (2/2), completed with 2 local objects. To github.com:Zhoufenmianfan/GitStudy.git ba2eadf..610e6ac deev -> deev
我自己同时也开发了功能，add+commit到自己本地后，尝试push到我们共同的远程库。推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 $ git status On branch deev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") $ git add readme.txt $ git commit -m "add:Step 11" [deev 20b6d5c] add:Step 11 1 file changed, 1 insertion(+), 1 deletion(-) $ git push origin deev To github.com:Zhoufenmianfan/GitStudy.git ! [rejected] deev -> deev (fetch first) error: failed to push some refs to 'github.com:Zhoufenmianfan/GitStudy.git' hint: Updates were rejected because the remote contains work that you do not hint: have locally. This is usually caused by another repository pushing to hint: the same ref. If you want to integrate the remote changes, use hint: 'git pull' before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 $ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (1/1), done. remote: Total 3 (delta 2), reused 3 (delta 2), pack-reused 0 Unpacking objects: 100% (3/3), 359 bytes | 1024 bytes/s, done. From github.com:Zhoufenmianfan/GitStudy ba2eadf..610e6ac deev -> origin/deev 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 <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/<branch> deev
git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
🧊使用命令git branch --set-upstream-to=origin/<branch> deev
1 2 3 4 5 6 7 8 $ git branch --set-upstream-to=origin/deev deev branch 'deev' set up to track 'origin/deev'. $ git pull Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result.
这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：然后解决冲突，add+commit+push
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 $ git add readme.txt $ git commit -m "fix env conflict" [deev 789d803] fix env conflict $ git status On branch deev Your branch is ahead of 'origin/deev' by 2 commits. (use "git push" to publish your local commits) nothing to commit, working tree clean $ git push origin deev Enumerating objects: 10, done. Counting objects: 100% (10/10), done. Delta compression using up to 16 threads Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 625 bytes | 625.00 KiB/s, done. Total 6 (delta 4), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (4/4), completed with 2 local objects. To github.com:Zhoufenmianfan/GitStudy.git 610e6ac..789d803 deev -> deev
分支变基 首先将开发的deev分支用非快速方式进行分支合并，
🧊使用命令git merge --no-ff -m "merge with no-ff" deev，并注意这种方式会创建一个commit，因此需要写上message。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 $ git switch main Switched to branch 'main' $ git merge --no-ff -m "merge with two features" deev Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result. $ git add readme.txt $ git merge --no-ff -m "merge with two features" deev fatal: You have not concluded your merge (MERGE_HEAD exists). Please, commit your changes before you merge. $ git commit -m "fix merge conflict" [main 367ac85] fix merge conflict $ git merge --no-ff -m "merge with two features" deev Already up to date. $ git log --graph --pretty=oneline --abbrev-commit * 367ac85 (HEAD -> main) fix merge conflict |\ | * 789d803 (origin/deev, deev) fix env conflict | |\ | | * 610e6ac add:add a feature:step11 | * | 20b6d5c add:Step 11 | |/ | * ba2eadf add:step10 * | b99d80c (origin/main) add:step10 * | bc2c1a8 delete:想想垃圾 * | 9059eaa merge with no-ff |\| | * 7ff15b7 add:merge feature1 |/ * a86de26 conflick fixed |\ | * 19d592e add:new a branch feature1 * | 9be30e1 add:Step 7 |/
在变基过程中出现了一些曲折因为之前数次错综复杂的加上远程库也进行了一次merge导致需要核对三次冲突，一起来看一下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 $ git rebase Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt error: could not apply ba2eadf... add:step10 hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". Could not apply ba2eadf... add:step10 $ git rebase fatal: It seems that there is already a rebase-merge directory, and I wonder if you are in the middle of another rebase. If that is the case, please try git rebase (--continue | --abort | --skip) If that is not the case, please rm -fr ".git/rebase-merge" and run me again. I am stopping in case you still have something valuable there. $ git add readme.txt $ git commit -m "fix rebase" [detached HEAD df12556] fix rebase 1 file changed, 1 insertion(+), 1 deletion(-) $ git rebase --continue Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt error: could not apply 20b6d5c... add:Step 11 hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". Could not apply 20b6d5c... add:Step 11 $ git add readme.txt $ git rebase --continue Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt error: could not apply 610e6ac... add:add a feature:step11 hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". Could not apply 610e6ac... add:add a feature:step11 $ git add readme.txt $ git rebase --continue [detached HEAD efa0d7b] add:add a feature:step11 1 file changed, 1 insertion(+) Successfully rebased and updated refs/heads/main. $ git log --graph --pretty=oneline --abbrev-commit * efa0d7b (HEAD -> main) add:add a feature:step11 * df12556 fix rebase * 5307602 (origin/main) Deev (#2) * b99d80c add:step10 * bc2c1a8 delete:想想垃圾 * 9059eaa merge with no-ff |\ | * 7ff15b7 add:merge feature1 |/ * a86de26 conflick fixed |\ | * 19d592e add:new a branch feature1 * | 9be30e1 add:Step 7 |/ * 62d62a4 add:new a branch dev * 241aeea addfile:cancel.txt * 9c6fad0 add:Step 5 * 674519f add:Step 4 * 6185ab1 add:Step 3; addfile:LICENSE * a71de4e add:Step 2 * 55fc0ac add:Step 1
原本分叉的提交现在变成一条直线了！这种神奇的操作是怎么实现的？其实原理非常简单。我们注意观察，发现Git把我们本地的提交“挪动”了位置，放到了前面的commit之后，这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。最后，通过push操作把本地分支推送到远程：
1 2 3 4 5 6 7 8 9 10 11 $ git push origin main Enumerating objects: 8, done. Counting objects: 100% (8/8), done. Delta compression using up to 16 threads Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 551 bytes | 551.00 KiB/s, done. Total 6 (delta 4), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (4/4), completed with 2 local objects. To github.com:Zhoufenmianfan/GitStudy.git 5307602..efa0d7b main -> main
