海曙网站设计建设wordpress主题wpmee

¹

1. git diff

如果忘记了修改了什么，可以使用此命令进行变更详情查看。

# 1. 查看当前目录指定文件与（暂存区）目录该文件之间的区别
git diff hwy.txt	
# 2. 查看当前目录，所有文件变更情况
git diff
# 3. 查看当前目录，与（最新的提交`HEAD`）之间的差异
git diff HEAD -- cxk.txt

---

---

---

---

2. git log

git log		# 详细的查看历史的所有commit版本

---

3. git reset

# 回退历史版本
git reset --hard HEAD^		# 回退到上一个commit版本
git reset --hard HEAD~5		# 向前回退5个commit版本
git reset --hard st34f2r	# 变更到指定某一个版本

---

4. git reflog

由于后退到某个历史版本后，git log就不会输出该版本之后的提交id，可以通过查看git命令执行日志，找到对应的提交ID，在进行commit版本变更。

git reflog

---

5. 提交撤销

5.1 当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时

git checkout -- cxk.txt			# 1. 撤回指定文件工作区中的修改

---

5.2 当提交到了stage区后，想要退回

git reset HEAD cxk.txt

• 场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
• 场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD <file>，就回到了场景1，第二步按场景1操作。
• 场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

---

6. git remote

# 1. 新建与远程仓库的链接
git remote add origin git@github.com:username/project_name.git# 2. 删除与远程仓库的链接
git remote -v			# 查看有哪些远程仓库链接
git remote rm xxxxxx	# rm删除与远程仓库的链接

---

7. git pull origin master --no-rebase

# 当遇到本地仓库有自己独有的文件，远程仓库有独有的文件，合并两个仓库
# 1. 重新生成一个提交，用于合并本地分支和远程仓库分支
git pull origin master --no-rebase# 2. 采用变基（rebase）策略，将本地分支的所有提交，在远程分支最新提交上”重新播放“，从而达到一个线性的提交历史
git pull origin master --rebase

---

8. 分支管理

git checkout -b dev		# 快速创建一个dev分支，并切换到该分支# 等价于如下
git branch dev
git checkout dev		

# 合并dev到当前所在分支
git merge dev

• 需要切换到指定分支，然后再将dev分支合并到指定分支.
• 创建分支，实际上只是创建了一个指向当前commit的一个指针，上述merge将会采用Fast-forward策略，快速合并；这是因为这种合并只是将master指针指向了dev当前commit所在的版本位置。
• 随后直接删除dev即可

---

9. git rebase

当本地分支需要与远程分支同步，但是远程分支已经有了新的版本，因此无法直接git push.

此时，需要先git pull origin master，将远程的分支与本地进行合并，但是这样一来，就会有很多分叉的历史提交线.

为了保证美观，因此可以考虑使用变基(rebase)

这里我演示一下rebase的工作原理

任务:

• 新建并切换到 bugFix 分支
• 提交一次
• 切换回 main 分支再提交一次
• 再次切换到 bugFix 分支，rebase 到 main 上

# 1. 创建bugFix分支，并切换过去
git checkout -b bugFix

2. 在bugFix分支提交一次，随后切回到main分支（这里就不打命令了）

3. 在main分支commit一次（这里就不打命令了）
git checkout bugFix		# 切到bugFix分支

# 4. 执行rebase合并（变基合并）
git rebase main

rebase工作原理可以解释为如下：

• 将c1->c2的变更操作，应用到main分支的最新提交位置，从而达到合并的效果。
• 因此，在main分支的最新提交处c3，新增了一个提交操作，从而到达了c2’；c3->c2'的文件变更情况与c1->c2一样

为了更详细的展示，这里举了一个多次commit的例子。

如下图，可以看到：

• bugFix的提交过程为C1->C2->C3
• main的提交过程为C1->C4->C5

执行rebase命令后，则会将C1->C2->C3的版本变更操作，执行到main分支的最新提交C5上;

从而得到一个使得历史提交版本线像是在同一条线上进行的，更加美观。

PS: merge和rebase的用户不同之处

• rebase：如果需要将A分支合并到B分支，则需要先切换到A分支，然后执行git rebase B，有种基于B，把当前分支提交合并进去的意思；
• merge：如果需要将A分支合并到B分支，那么直接切到B分支作为骨干，执行git merge A，有种将A拉过来合并的意思。

10. git cherry-pick（选择性提交）

# 顾名思义，筛选，挑拣。
# 意思是指定一些commit，合并到当前所在分支。
git cherry-pick c3 c4 (可接多个提交版本)

举个例子，下图共有4个分支，当前处于main分支，现在想要吧c3，c4，c7三个提交，合并到main分支上。

神奇的事情来了，通过执行如下命令，完成筛选合并。

可以发现，main分支从当前位置c1开始，依次提交c3 c4 c7

git cherry-pick c3 c4 c7

总结

最后，个人学习过程中用到的网站如下：

• 基础概念：廖雪峰-git教程
• 模拟实战：Learn Git Branching
• 本地模拟：在本地模拟一个git远程仓库

2023.09.01

---

1. 工作区和暂存区 ↩︎