git 使用心得

git使用技巧推荐文章

git 四个工作区

• Remote Repository：远程仓库
• Local Repository：本地仓库
• staging：暂存区
• workspace：工作区

1、远程仓库

位于托管代码的服务器，远程仓库的内容能够被分布在多个地点的处于协作关系的本地仓库修改。比起本地仓库，远程仓库通常旧一些，因此本地仓库修改完之后需要同步到远程仓库。

2、本地仓库

位于自己的机器，本地仓库保存了被提交过的各个版本，比起工作区和暂存区的内容，它更旧一些。

首先是 git commit 同步 index 的目录树到本地仓库，然后通过 git push 同步本地仓库到远程仓库。

3、暂存区

位于.git目录下的index文件，暂存区会记录 git add 添加文件的相关信息（文件名、大小），不保存文件实体，通过 id 指向每个文件的实体。

使用 git status 可以查看暂存区的状态，暂存区标记了当前工作区中那些内容是被 git 管理的，当完成某个需求或者功能后需要提交代码，第一步就是通过 git add 先提交到暂存区。

4、工作区

即进行开发改动的地方，是当前看到的，内容也是最新的，平常开发就是拷贝远程仓库中的分支，基于该分支进行开发，在开发的过程就是在工作区的操作。

git的工作流程

1.在工作区开发，添加，修改文件。
2.将修改后的文件放入暂存区。
3.将暂存区域的文件提交到本地仓库。
4.将本地仓库的修改推送到远程仓库。

git 的基本操作

git add

git add 命令用于将文件或目录的更改添加到 Git 的暂存区，以准备进行下一步的提交操作。

# 添加某个文件到暂存区，后面可以跟多个文件，以空格区分
git add xxx
# 添加当前更改的所有文件到暂存区。
git add .

git commit

git commit 命令用于创建一个新的提交，将当前暂存区中的更改保存到 Git 仓库中。

# 提交暂存的更改，会新开编辑器进行编辑
git commit 
# 提交暂存的更改，并记录下备注
git commit -m "you message"
# 等同于 git add . && git commit -m
git commit -am
# 对最近一次的提交的信息进行修改,此操作会修改commit的hash值
git commit --amend

git pull

git pull 命令用于从远程仓库获取最新的提交，并将其合并到当前分支。

# 从远程仓库拉取代码并合并到本地，可简写为 git pull 等同于 git fetch && git merge 
git pull <远程主机名> <远程分支名>:<本地分支名>
# 使用rebase的模式进行合并
git pull --rebase <远程主机名> <远程分支名>:<本地分支名>

git fetch

git fetch 命令用于从远程仓库获取最新的提交历史和对象, 与 git pull 不同的是 git fetch 操作仅仅只会拉取远程的更改，不会自动进行 merge 操作。对你当前的代码没有影响。

# 获取远程仓库特定分支的更新
git fetch <远程主机名> <分支名>
# 获取远程仓库所有分支的更新
git fetch --all

git branch

git branch 命令用于管理 Git 仓库中的分支。

# 新建本地分支，但不切换
git branch <branch-name> 
# 查看本地分支
git branch
# 查看远程分支
git branch -r
# 查看本地和远程分支
git branch -a
# 删除本地分支
git branch -D <branch-nane>
# 重新命名分支
git branch -m <old-branch-name> <new-branch-name>

git cherry-pick

git cherry-pick 命令用于将一个或多个提交从一个分支应用到当前分支。它允许您选择性地选择特定的提交并将其应用到目标分支上。

# 执行 cherry-pick 操作时不自动创建新的提交。这样可以避免自动创建提交，以便在应用完整的更改后手动进行提交。
git cherry-pick -n (--no-commit) <commit>

# 在应用提交时打开编辑器，以便您可以对提交消息进行编辑。
git cherry-pick -e (--edit) <commit>

# 在应用提交时添加 "Signed-off-by" 行，显示作者同意提交内容。
git cherry-pick -x (--signoff) <commit>

# 指定父提交编号（1、2 等）用于合并提交。适用于合并提交的 cherry-pick 操作。
git cherry-pick -m (--mainline) parent-number <commit>

# 指定 cherry-pick 使用的合并策略选项，例如 `recursive`、`resolve` 等
git cherry-pick -s (--strategy) <strategy-option> (recursive | resolve) <commit>

git revert

git revert 命令用于撤销一个或多个提交的更改，并创建一个新的提交来表示此撤销操作。

git revert <commit> <commit>

git remote

git remote 命令用于管理 Git 仓库中的远程仓库。

# 添加一个新的远程仓库，并指定名称和 URL。 
git remote add <name> <url> 

# 将已存在的远程仓库重命名为新的名称。 
git remote rename <old-name> <new-name> 

# 移除指定名称的远程仓库。 
git remote remove <name> 或 git remote rm <name> 

# 显示指定名称的远程仓库的详细信息。
git remote show <name> 

# 获取指定名称远程仓库的 URL。 
git remote get-url <name> 

# 设置指定名称远程仓库的 URL。 
git remote set-url <name> <new-url> 

# 设置指定名称远程仓库的 HEAD 引用。 
git remote set-head <name> <branch> 

# 移除指定名称远程仓库中不存在的引用。
git remote prune <name> 

# 更新所有远程仓库或指定分组的远程仓库。
git remote update 或 git remote update <group> 

# 显示更详细的输出。 
git remote -v 或 git remote --verbose

git reset

git reset 命令用于撤销提交、移动分支指针或重置暂存区。

# 撤销提交
git reset <commit>

# 移动分支指针
git reset <commit> --hard

# 重置暂存区
git reset

git checkout

git checkout 命令用于切换分支、还原文件或检出提交。

# 切换到指定名称的分支。
git checkout <branch>

# 检出指定提交，并进入分离头状态。
git checkout <commit>

# 创建并切换到一个新的本地分支。
git checkout -b <branch-name>

# 在创建本地分支时自动与远程分支建立跟踪关系。
git checkout --track <remote-branch>

# 强制检出，丢弃本地修改并进行检出操作。
git checkout -f <branch-or-commit>

# 在检出操作后执行合并，将当前分支与目标分支合并。
git checkout --merge <branch>

# 在合并冲突时选择保留当前分支的更改。
git checkout --ours <files>

# 在合并冲突时选择保留目标分支的更改。
git checkout --theirs <files>

git stash

git stash 命令用于临时保存当前工作目录中的修改，以便您可以切换到其他分支或进行其他操作。

# 将当前工作目录中的修改保存到一个新的存储项（stash）中。
git stash save "Work in progress"

# 显示所有保存的存储项的列表。
git stash list

# 将最新的存储项应用到当前分支，并保留存储项。
git stash apply [<stash>]

# 将最新的存储项应用到当前分支，并从存储项列表中删除该存储项。
git stash pop [<stash>]

# 从存储项列表中删除指定的存储项。
git stash drop <stash>

# 清空所有存储项。
git stash clear

git merge

git merge 命令用于将一个分支的更改合并到当前分支

# 执行非快进合并，即创建一个新的合并提交，即使没有冲突。
git merge --no-ff

# 仅执行快进合并，如果无法快进合并，则不执行合并操作。
git merge --ff-only

# 将要合并的提交压缩成一个单独的提交，而不会创建合并提交。
git merge --squash

# 在合并提交时自定义合并消息。
git merge -m "Custom merge message"

# 取消当前的合并操作，并回到合并之前的状态。
git merge --abort

# 指定合并策略选项，如 recursive、resolve、ours 等。
git merge -s <strategy>

git rebase

git rebase 命令用于将一系列提交以变基的方式应用到另一个分支上。

# 启动交互式模式，允许对重演操作进行交互式调整。
git rebase -i <commit>

# 指定要将当前分支的提交应用到的目标分支。
git rebase <upstream>

# 指定要执行交互式重演的分支。
git rebase <branch>

# 指定一个新的基准点（基础提交），用于限制重演操作的范围。
git rebase --onto <new-base>

# 在重演操作中保留合并提交，而不是简化为线性提交历史。
git rebase -p 或 git rebase --preserve-merges

# 跳过当前正在处理的提交，继续进行下一个重演操作。
git rebase --skip

# 取消当前的重演操作，并回到重演之前的状态。
git rebase --abort

git merge 和 git rebase 的区别

• 不同于 git rebase 的是，git merge 在不是 fast-forward（快速合并）的情况下，会产生一条额外的合并记录，类似 Merge branch 'xxx' into 'xxx' 的一条提交信息。

另外，在解决冲突的时候，用 merge 只需要解决一次冲突即可，简单粗暴，而用 rebase 的时候 ，需要依次解决每次的冲突，才可以提交。

git rebase 交互模式

在开发中，常会遇到在一个分支上产生了很多的无效的提交，这种情况下使用 rebase 的交互式模式可以把已经发生的多次提交压缩成一次提交，得到了一个干净的提交历史，例如某个分支的提交历史情况如下：

注意！！已经在远程merge的提交尽量不要rebase，造成的冲突是要一个冲突一个冲突解决的，所以此操作尽量在个人的本地分支完成

进入交互式模式的方式是执行：

git rebase -i <base-commit>

参数 base-commit 就是指明操作的基点提交对象，基于这个基点进行 rebase 的操作，对于上述提交历史的例子，比如现在我要把收货地址优化之前的提交压缩成一次提交，我们需要执行的命令格式是：

git rebase -i fb476335

此时会进入一个 vim 的交互式页面，编辑器列出的信息像下列这样

想要合并这一堆更改，我们要使用 Squash 策略进行合并，即把当前的 commit 和它的上一个 commit 内容进行合并， 大概可以表示为下面这样，在交互模式的 rebase 下，至少保留一个 pick，否则命令会执行失败。

pick 86ee9ac5 feat: 订单确认-发货清单-未完成
pick bf1ddae1 feat: 教程页面

# 变基 fb476335..bf1ddae1 到 fb476335（2 个提交）
#
# 命令:
# p, pick <提交> = 使用提交
# r, reword <提交> = 使用提交，但修改提交说明
# e, edit <提交> = 使用提交，进入 shell 以便进行提交修补
# s, squash <提交> = 使用提交，但融合到前一个提交
# f, fixup <提交> = 类似于 "squash"，但丢弃提交说明日志
# x, exec <命令> = 使用 shell 运行命令（此行剩余部分）
# b, break = 在此处停止（使用 'git rebase --continue' 继续变基）
# d, drop <提交> = 删除提交
# l, label <label> = 为当前 HEAD 打上标记
# t, reset <label> = 重置 HEAD 到该标记
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       创建一个合并提交，并使用原始的合并提交说明（如果没有指定
# .       原始提交，使用注释部分的 oneline 作为提交说明）。使用
# .       -c <提交> 可以编辑提交说明。
#
# 可以对这些行重新排序，将从上至下执行。

在刚刚的vim界面里面将教程和发货清单进行 squash 合并，进入vim编辑模式 的快捷键是i，将bf1ddae1 前面的pick改为 s 或者 squash，按esc键退出编辑模式后按 shift + ；输入wq 保存

此时进入第二个vim界面

确认下提交信息，继续shift + ；输入wq 保存

此时我们的代码已经变基更新了，再去观察我们的分支图

可以看到commit信息已经变更了，上面的两个已经合并为一个了

rebase 后的代码能回滚吗

当然是可以的，我们在本地开发的时候，所有的代码提交记录都是会被记录下来的。首先使用git reflog 命令进入到git 提交历史记录的界面

可以看到我们所有的变更记录都在上面，我们只需重置到之前的基点就好了,从上面的信息可以看到，我们rebase 之前的基点hash是bf1ddae1，我们只需回滚到这个基点即可，按q 退出reflog，然后执行下面的命令

git reset --hard bf1ddae1

现在已经恢复到了变基之前的样子了

使用 git cherry-pick 获取指定的 commit

现在假设一种场景，我做了一部分优化的需求，但是commit分散在了 1.1.0 的分支

现在测试要求我从这个版本转到另一个版本里面去提测，应该怎么做？

首先，我从master版本拉出来新的分支，就以提测的版本命名，比如叫1.1.0.1,现在我从master签出新分支，执行

 git checkout -b 1.1.0.1 origin/master

现在开始从1.1.0.1分支拿到指定的commit hash值，在上面的截图上有简版的hash，执行命令

git cherry-pick -i ef5b7ff1 12a149d5 66ba1d00

此时可以看到，那边的提交已经在这个1.1.0.1分支了

但是那边已经提交的应该怎么办呢？我们不希望这边的代码被拿到1.1.0分支上，接下来就要用到revert命令进行重置了，我们继续执行命令，先签出revert-1.1.0分支

 git checkout -b revert-1.1.0 origin/1.1.0

然后执行revert 命令将刚刚那三个commit 进行还原

git revert -i ef5b7ff1 12a149d5 66ba1d00

执行命令后，会进入vim编辑页面，里面是关于这次revert的变更信息

如果提交的信息不需要什么更改的就按esc键后 shift + ；输入wq进行保存

此时会生成三个revert的提交，然后将这个revert-1.1.0 分支合并到1.1.0分支上，相关的提交就会被回滚掉了,然后我们的1.1.0.1 就可以愉快的提测了，顺便再通知提测1.1.0里面的更改已经回滚了