Git使用集锦（常见命令及使用场景）

基础（本地仓库）

git commit（提交）

• 创建一个新的提交记录：git commit

git branch（分支）

• 使用分支＝我想基于这个提交以及它所有的父提交进行新的工作：git branch newName
• 切换到新的分支：git checkout git
• 创建新的分支并同时切换到该新分支：git checkout -b

git merge（分支合并）

• 合并两个分支时会产生一个特殊的提交记录，它包含两个父节点
• 合并分支＝我要把这两个父节点本身及它们所有的祖先都包含进来
• 将bugFix合并到main里：git merge branchName（前提是当前分支为main分支）完整过程如下图所示：

 git rebase（分支合并）

• 取出一系列的提交记录，复制它们并在另一个地方逐个的放下去，可以创造更线性的提交历史
• 转移分支内容：git rebase main（将bugFix分支的内容复制到main分支下，看起来是顺序开发，实际上还是并行开发）
• 分支内容转移后，提交记录依然在原来的位置，main下方的记录只是一个副本

 在提交树上移动（head） 

• 对当前检出记录的符号引用：指向正在其基础上进行工作的提交记录
• 总是指向当前分支上的最近一次提交记录（通常指向分支名），大多数修改提交树的git命令都是从改变head的指向开始的

相对引用

• 查看提交记录的哈希值：git log
• 向上移动一个提交记录：^

• 向上移动多个提交记录：~ 不跟数字时默认值向上移动一次
  • 如：git checkout HEAD~4
• 强制修改分支位置：-f

撤销变更（git reset/git revert）

• git reset（本地变更，对远程分支无效）
  • 向上移动分支，原来指向的提交记录就跟从来没有提交过一样
  • 当reset将main分支移回到c1提交之后，c2做的变更还在，只是处于了未加入暂存区的状态
• git revert（可远程变更）
  • revert之后的更改可以推送到远程仓库与别人分享
  • revert变更之后会多一个新的提交记录，这个新的提交记录实际上是用来撤销原来的提交的，也就是说这个新的提交的状态与原来提交的上一级提交是一样的。如下图中，c2'的状态和c1的状态其实就是相同的

 整理提交记录

•  git cherry-pick<提交号> 前提是知道所需要的提交记录

交互式rebase

• 使用带参数的--interactive的rebase命令，简写为-i，当在命令后增加了这个选项时，git会打开一个UI界面并列出将要被复制到目标分支的备选提交记录，还会显示每个提交记录的哈希值和提交说明（提交说明可以帮助理解这个提交进行了哪些更改）
• 实际使用时，UI窗口一般会在文本编辑器中打开一个文件
• 当rebase UI界面打开时，可以进行下面几个操作：
  • 调整提交记录的顺序（鼠标拖动）
  • 删除不想要的提交（切换pick状态，关闭就表示需要删除这个提交记录）
  • 合并提交，将多个提交记录合并成一个
• git rebase -i HEAD~
• 优点：让提交树变得干净，所有的提交都汇聚在一条线上
• 缺点：修改了提交树的历史

提交的技巧

• 之前在newImage分支上进行了一次提交，然后基于它创建了caption分支，又提交了一次，此时对以前的提交记录进行调整：

上图对应命令如下：
git rebase -i HEAD~2 #修改C2和C3的顺序
git commit --amend
git rebase -i HEAD~2 #修改C3'和C2''顺序
git branch -f main

•  git cherry-pick技巧

上图对应命令如下：
git checkout master
git cherry-pick newImage
git commit --amend
git cherry-pick caption

git tags

• 在某种程度上永久地将某个特定的提交命名为里程碑，然后就可以像分支一样引用了（标签可以被删除后重新在另外一个位置创建同名的标签）
• 他们不会随着新的提交而移动，也不能检出到某个标签上面进行修改提交，它就像是一个锚点，标识了某个特定的位置。

git describe

• 描述距离最近的锚点（标签）
• 可以帮助在提交历史中移动了多次以后找到方向

• git describe ：ref可以是任何能被git识别成提交记录的引用，如果没有指定，git会以目前所检出的位置 

 两个父节点

• 选择父提交记录
• 操作符^和~一样，后面也可以跟数字，但是^后跟数字不是用来指向向上返回几代，而是指定合并提交记录的某个父提交。
• 之前利用merge进行分支合并时会产生两个父节点，此时该选择哪一条路径就不太清晰，git中默认选择合并提交的第一个父提交，在操作符^后跟一个数字可以改变这一默认行为。

上图对应命令：git branch bugWork HEAD~^2~

上图对应命令如下：
git checkout one
git cherry-pick c4 c3 c2
git checkout two
git cherry-pick c5 c4 c3 c2
git branch -f three c2

远程仓库

1. 远程仓库是一个强大的备份。本地仓库也有恢复文件到指定版本的能力，但是所有信息都是保存在本地的。而使用远程仓库，即使丢失了本地的所有数据，也可以通过远程仓库拿回丢失的数据。
2. 远程仓库可以让代码社交化，当代码长传到远程仓库后，他人可以更容易地为项目做贡献（拉去最新的项目变更）
3. 目前常用的远程仓库可视化操作有GitHub和Phabricator等。
4. 远程仓库的操作主要有两点：向远程仓库传输数据以及从远程仓库获取数据。

git clone

•  在真实环境下用于在本地创建一个远程仓库的拷贝

远程分支

• 远程分支反映了远程仓库（上次和它通信时）的状态
• 检出时自动进入分离head状态
• 需要在别的地方完成工作，更新远程分支之后再用远程分享工作成果
• 远程分支命名规范：/；举个例子：如果一个分支名为origin/main，那么这个分支名为main，远程仓库的名称为origin。
• 当git clone仓库时，git会默认将远程仓库的名称设置为origin
• 检出分支：git checkout origin/main

git fetch

• 从远程仓库获取数据，在进行数据获取时，远程分支也会更新以反映最新的远程仓库
• git fetch的作用：
  • 从远程仓库下载本地仓库中缺失的提交记录
  • 更新远程分支指针（如origin/main）
• 实际上就是将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态
• git fetch通常通过互联网（使用http:// 或者 git:// 协议）与远程仓库进行通信
• git fetch不会改变本地仓库的状态，不会更新main分支，也不会修改磁盘上的文件，可以将git fetch理解为单纯的下载操作

git pull

• 当远程分支中有新的提交时，可以像合并本地分支一样进行远程分支的合并

•  git pull = git fetch + git merge origin/main

git push

• 将变更内容上传到指定的远程仓库，并在远程仓库合并新提交记录，push完成后，他人就可以从该远程仓库获取上传的内容
• git push不带任何参数时的行为与git中push.default配置有关，它的默认值取决于git的版本，在项目中进行推送之前，最好先进行这个配置的检查。

偏离的工作

• git pull --rebase = git fetch + git rebase

上图对应命令如下：
git clone
git fakeTeamwork 1
git commit
git pull --rebase
git push

远程服务器拒绝（remote rejected）

•  远程服务器拒绝直接推送提交到main，因为策略配置要求pull requests来提交更新
• 解决：新建一个分支feature，推送到远程服务器，然后reset一下main分支和远程服务器保持一致，否则下一次pull时如果和他人的提交发生冲突就会出现问题

上图对应命令如下：
git reset --hard origin/main
git checkout -b feature c2
git push origin feature

合并特性分支，推送主分支

 

 

上图对应命令如下：
git retch
git rebase origin/main side1
git rebase side1 side2
git rebase side2 side3
git rebase side3 main
git push

合并远程仓库

 

上图对应命令如下：
git checkout main
git pull origin main
git merge side1
git merge side2
git merge side3
git push origin main

远程跟踪分支

• main和origin/main的关联关系由分支的remote tracking属性决定；main被设定为跟踪origin/main，这意味着main分支制定了推送的目的地以及拉取后合并的目标。（remote tracking属性在克隆仓库时会自动设置）
• 在进行克隆时，git会为远程仓库中的每一个复制都在本地仓库中创建一个远程分支（如origin/main），然后再创建一个跟踪远程仓库中活动分支的本地分支，默认情况下这个本地分支会被命名为main
• 克隆完成后，可以得到一个本地分支（如果没有这个本地分支，就说明目录是空白的），但是可以查看远程仓库中所有的分支。
• 基于以上原因，当进行克隆后，会出现这样的输出：local branch "main" set to track remote branch "origin/main"
• 可以让任意分支跟踪origin/main，然后该分支会像main分支一样得到隐含的push目的地以及merge的目标，也就意味着可以在分支totallyNotMain上执行git push，将工作推送到远程仓库的main分支上
• 可以指定remote tracking属性
  • 方法一：通过远程分支检出一个新的分支：git checkout -b 命令，如git checkout -b totallyNotMain origin/main，创建一个名为totallyNotMain的分支来跟踪远程分支origin/main
  • 方法二：设置远程追踪分支：git branch -u 命令，如git branch -u origin/main foo，使用foo分支跟踪origin/main；如果当前分支就是foo分支，则可以省略foo：git branch -u origin/main

上图对应命令如下：
git checkout -b side origin/main
git commit
git pull --rebase
git push

git push的参数

•  为push指定参数：git push
• 举个栗子：pit push origin main（切换到本地仓库中的main分支获取所有提交，再到远程仓库origin中找到main分支，将远程仓库中没有的提交记录都进行添加）
• 通过place参数告知git提交记录来自于main，要推送到远程仓库中的main，实际就是要同步两个仓库的位置
• 因为通过指定参数告知了git所有它需要的信息，所以git就忽略了所检出的分支属性

place参数详解

• 当为git push指定参数place为main时，同时也就指定了提交记录的来源和去向，但是当来源和去向分支的名称不同（比如要将本地的foo分支推送到远程仓库中的bar分支），需要使用“:”进行连接
• git push origin :，source是任何git可以识别的位置
• 如果要推送到的目的分支不存在，git会在远程仓库中根据提供的名称进行这个分支的创建

 

 

上图对应命令如下：
git push origin foo:main
git push origin main^:foo

git fetch的参数

•  git fetch的参数和git push的参数很相似，只是方向不同
• 参数，如：git fetch origin foo，git会在远程仓库的foo分支上，获取所有本地不存在的提交，然后放在本地的origin/foo上

上图对应命令如下：
git fetch origin master^:foo
git fetch origin foo:master
git checkout foo
git merge master

• 在git push 和 git fetch时，不指定任何source，仅保留冒号和destination部分，source部分留空，如git push origin :side，git fetch origin :bugFix
• git push origin :destination：删除远程仓库中的destination分支
• git fetch origin :destination：在本地创建一个destination分支

git pull参数

• pit pull origin foo = git fetch origin foo + git merge origin/foo
• git pull origin bar~1:bugFix = git fetch origin bar~1:bugFix + git merge bugFix

上图对应命令如下：
git pull origin bar:foo
git pull origin main:side

ps：

推荐给大家这个链接，进行git的学习和运用，从浅入深讲的还不错，常用的一些命令和情景基本都涉及到了。https://learngitbranching.js.org/?demo=&locale=zh_CN