每个开发人员都应该对版本控制有很好的理解, Git已经成为软件开发中版本控制的事实上的标准.

Often though, 开发人员只学习了几个简单的命令，而忽略了Git历史的强大功能和Git可以做的其他事情，从而使您更有效率. 例如，使用Git可以很容易地管理发布 git tag.

我参加了Git在线高级课程(与Github)，并继续与Github一起教授初学者的Git课程. 当我注意到没有很多关于我最喜欢的Git特性的技术文章时, 我抓住这个机会与其他开发者分享. 在这篇文章中，你将学习如何利用以下高级Git函数:

• git stash，这将对代码进行临时的本地保存
• git reset，它可以让您在提交之前整理代码
• git bisect，一个允许您查找错误提交的函数
• git squash，它允许您合并提交
• git rebase，它允许将更改从一个分支应用到另一个分支

Git Stash

Git stash使您无需提交即可保存代码. 这有什么用?? 想象一下下面的场景:

您已经完成了三次整洁的提交, but you also have some uncommitted code that’s quite messy; you won’t want to commit it without removing your debugging code first. 然后，由于某种原因，您突然需要处理另一项任务，不得不切换分支. 这种情况经常发生，如果你在你的 main 分支，而您忘记为您的特性创建一个新的分支. 现在，你的代码看起来像这样:

$ git status
在分支my-feature上
未提交的更改:
  (use "git add ...“更新将要提交的内容”。
  (use "git checkout -- ..."放弃工作目录中的更改)

	修改:css /常见.scss

提交时不添加任何更改(使用"git add"和/或"git commit -a")

$ git diff
/css/common.scss b / css /常见.scss
index 2090cc4..90fd457 100644
——/ css /常见.scss
+ + + b / css /常见.scss
@@ -13,6 +13,6 @@
 body {
     font-family: "Proxima Nova"， Arial, sans-serif;
     字体大小:13 px;
-颜色:#333;
+颜色:红色;
     background - color: # f00;
 }

When you run git stash，未提交的代码在未提交的情况下消失. 隐藏类似于将临时本地提交保存到分支. 不可能将存储库推送到远程存储库, 所以私藏是你自己用的.

$ git stash
保存工作目录和索引状态WIP在my-feature: 49ee696更改文本颜色

您的分支现在显示为您上次提交时的样子. 现在，您可以安全地更改分支，而不会丢失代码或导致提交混乱. 当你切换回你的分支并运行 git stash list 你会看到一个隐藏列表，看起来像这样:

$ git收藏列表
stash@{0}: WIP on my-feature: 49ee696更改文本颜色

可以很容易地重新应用隐藏的内容 git stash apply. 您还可以通过运行应用特定的存储(如果您已经存储了多次) {1} (“1”表示倒数第二笔钱). 下面是一个存储多个提交并应用不同存储的示例:

$ git diff
/css/common.scss b / css /常见.scss
index 2090cc4..90fd457 100644
——/ css /常见.scss
+ + + b / css /常见.scss
@@ -13,6 +13,6 @@
 body {
     font-family: "Proxima Nova"， Arial, sans-serif;
     字体大小:13 px;
-颜色:#333;
+颜色:红色;
     background - color: # f00;
 }
$ git stash
保存工作目录和索引状态WIP在my-feature: 49ee696更改文本颜色
$ git diff
/css/common.scss b / css /常见.scss
index 2090cc4..b63c664 100644
——/ css /常见.scss
+ + + b / css /常见.scss
@@ -13,6 +13,6 @@
 body {
     font-family: "Proxima Nova"， Arial, sans-serif;
     字体大小:13 px;
-颜色:#333;
+颜色:红色;
     background - color: # f00;
 }
$ git stash
保存工作目录和索引状态WIP在my-feature: 49ee696更改文本颜色

$ git收藏列表
stash@{0}: WIP on my-feature: 49ee696更改文本颜色
stash@{1}: WIP on my-feature: 49ee696更改文本颜色
stash@{2}: WIP on my-feature: 49ee696更改文本颜色

$ {2}
在分支my-feature上
未提交的更改:
  (use "git add ...“更新将要提交的内容”。
  (use "git checkout -- ..."放弃工作目录中的更改)

	修改:css /常见.scss

提交时不添加任何更改(使用"git add"和/或"git commit -a")

{2} 当我们将文本颜色更改为红色时，是否应用了最古老的隐藏代码.

$ git diff
/css/common.scss b / css /常见.scss
index 2090cc4..90fd457 100644
——/ css /常见.scss
+ + + b / css /常见.scss
@@ -13,6 +13,6 @@
 body {
     font-family: "Proxima Nova"， Arial, sans-serif;
     字体大小:13 px;
-颜色:#333;
+颜色:红色;
     background - color: # f00;
 }

如果您决定在恢复存储库后不提交您的工作，则可以运行 git checkout .，重置所有未提交的代码.

作为如何使用Git stash的另一个例子:假设您有一些新文件，其中一个有错误. 除了可疑的bug文件外，其余所有文件都保持未分级(代码必须分级才能被隐藏), 然后，您可以隐藏该文件并对问题进行故障排除. 如果存储的文件不是问题所在，则可以恢复存储.

$ git status
在分支my-feature上
无路径的文件:
  (use "git add ...(包含在将要承诺的内容中)

	css/colors.scss

提交时没有添加任何内容，但存在未跟踪的文件(使用“git add”来跟踪)

$ git添加css/colors.scss 
$ git stash
保存工作目录和索引状态WIP在my-feature: 0d8deef删除颜色
$ git status
在分支my-feature上
没有什么要承诺的，工作树干净
$ git stash apply stash@{0}
在分支my-feature上
要提交的更改:
  (use "git reset HEAD ..." to unstage)

	新文件:css/colors.scss

您还可以将已隐藏的提交转移到新的特性分支或调试分支 git stash branch:

$ git status
在分支my-feature上
未提交的更改:
  (use "git add ...“更新将要提交的内容”。
  (use "git checkout -- ..."放弃工作目录中的更改)

	修改:css /常见.scss

提交时不添加任何更改(使用"git add"和/或"git commit -a")
$ git stash
保存工作目录和索引状态WIP在my-feature: 66f3f3b添加颜色文件
$ git stash分支调试分支
M	css/common.scss
切换到新的分支“debugging-branch”
重置后的非分级更改:
M	css/common.scss
在分支上调试分支
未提交的更改:
  (use "git add ...“更新将要提交的内容”。
  (use "git checkout -- ..."放弃工作目录中的更改)

	修改:css /常见.scss

{0} (d140624f60d8deef7bceb0d11fc80ed4fd47e0a1)

请注意，应用存储库时，不会删除存储库. 您可以使用 git drop，或使用 git stash clear:

$ git收藏列表
stash@{0}: WIP on my-feature: 66f3f3b添加颜色文件
stash@{1}: WIP上的我-特征:0d8deef删除颜色
stash@{2}: WIP on my-feature: 49ee696更改文本颜色
$ git drop stash@{2}
丢失的藏匿物@{2}(8ed6d2ce101aa2e28c8ccdc94cb12df8e5c468d6)
$ git收藏列表
stash@{0}: WIP on my-feature: 66f3f3b添加颜色文件
stash@{1}: WIP上的我-特征:0d8deef删除颜色
清理git库
$ git收藏列表
$

Git Reset

如果您发现自己不小心提交了一些混乱的代码, 你可以做一个“软”复位. 这意味着代码看起来好像还没有提交. 然后，您可以在IDE中整理代码，然后再进行更清晰的提交. 要做到这一点，您可以运行 git复位—软头~1. 这将重置最近的提交. 您可以通过更改提交后的编号来重置多个提交 ~ e.g. git复位-软头~2.

$ git reset—soft HEAD~1
$ git status
在分支上调试分支
要提交的更改:
  (use "git reset HEAD ..." to unstage)

	修改:css /常见.scss

未提交的更改:
  (use "git add ...“更新将要提交的内容”。
  (use "git checkout -- ..."放弃工作目录中的更改)

	修改:css /常见.scss

$ git diff
/css/common.scss b / css /常见.scss
index 2090cc4..90fd457 100644
——/ css /常见.scss
+ + + b / css /常见.scss
@@ -13,6 +13,6 @@
 body {
     font-family: "Proxima Nova"， Arial, sans-serif;
     字体大小:13 px;
-颜色:$灰色;
+颜色:红色;
     background - color: # f00;
 }

Git重置有点令人困惑，特别是在教授新的Git用户时. 软重置应该保留给真正的错误，而隐藏可以用来交换代码.

您也可以执行硬重置(git reset—hard HEAD~1). 这种类型的重置基本上会擦除上次提交. 在执行硬重置时应该非常小心, 尤其是当你推树枝的时候, 因为无法恢复您的提交.

Git Bisect

我最喜欢的Git工具是 git bisect. 我只需要它几次，但当我这样做的时候，它是无价的! 我主要在大型代码库中使用它，其中存在一个问题，但没有人找到根本原因, 即使经过一些有力的调试.

git bisect 本质上是在两个给定的提交之间执行二进制搜索，然后向您显示特定提交的详细信息. 首先需要给Git一个好的提交, 你知道你的功能在哪里工作, 一个糟糕的承诺. 请注意，只要你有一个好的提交和一个坏的提交, 这些提交可能相隔数年(尽管时间越久远), 它变得越困难!).

最有趣的事情是 git bisect 在开始时，您通常不知道是谁编写了有bug的提交. 发现漏洞出现的兴奋不止一次让一些同事挤在我的电脑旁!

首先，检查出有bug的分支并找到好的提交. 您需要浏览提交历史并找到提交散列, 然后签出那个特定的提交并测试你的分支. 一旦你找到一个好的和坏的工作地点，你可以运行一个 git bisect.

在这个场景中，我们制作的网站上的文本是红色的 (虽然它可以使用UI设计器) 但我们不知道它是如何或何时变成红色的. 这是一个非常简单的例子, 在现实生活中，你可能会遇到一个不那么明显的问题.g. 未提交/未运行的表单.

When we run a git log，我们可以看到要选择的提交列表.

$ git log
commit a3cfe7f935c8ad2a2c371147b4e6dcd1a3479a22 (HEAD -> main)
Author: Ursula Clarke 
日期:1月11日星期二10:52:57 2021 +0100

    Update .的Gitignore文件 .DS_Store

提交246年e90977790967f54e878a8553332f48fae6edc
Author: Ursula Clarke 
日期:1月11日星期二10:51:23 2021 +0100

    更改页面样式

提交d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e
Author: Ursula Clarke 
日期:1月11日星期二10:50:48 2021 +0100

    更改文本颜色

提交032年a41136b6653fb9f7d81aef573aed0dac3dfe9
Author: Ursula Clarke 
日期:1月11日星期二10:42:57 2021 +0100

    更改文本颜色

提交246年e90977790967f54e878a8553332f48fae6edc
Author: Ursula Clarke 
日期:1月11日星期二10:41:23 2021 +0100

    delete colors

提交d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e
Author: Ursula Clarke 
日期:1月11日星期二10:50:48 2021 +0100

    更改文本颜色

提交ce861e4c6989a118aade031020fd936bd28d535b
Author: Ursula Clarke 
日期:1月11日星期二10:07:36 2021 +0100

...

如果我在最近的提交哈希上打开我的网页，文本是红色的，所以我知道我有问题.

现在我们开始分割，并告诉Git我们有一个错误的提交.

$ git bisect start
$ git bisect bad 8d4615b9a963ef235c2a7eef9103d3b3544f4ee1

现在我们回到过去，试图找到一个文本不是红色的提交. 这里我试着检查我的第一次提交…

$ git checkout ce861e4c6989a118aade031020fd936bd28d535b
注:查看“ce861e4c6989a118aade031020fd936bd28d535b”.

你处于“分离的头脑”状态. 你可以环顾四周，进行实验
更改并提交它们，您可以丢弃在此中所做的任何提交
状态，而不会通过执行另一个签出影响任何分支.

如果您想创建一个新的分支来保留您创建的提交，您可以这样做
通过再次使用-b和checkout命令来执行(现在或以后). Example:

  git checkout -b 

添加CSS样式

和刷新网页…

文本不再是红色的，所以这是一个很好的提交! 更新的提交commit- i.e.，越接近错误的提交越好;

$ git checkout d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e
之前的HEAD位置是ce861e4c6989a118aade031020fd936bd28d535b添加CSS样式
HEAD现在在d647ac4更改文本颜色

Git现在会告诉你在找到正确的提交之前它需要搜索多少个提交. Git将遍历的提交数量取决于在好提交和坏提交之间有多少提交(较长的时间长度), Git需要迭代的次数就越多).

现在，您需要再次测试分支，看看问题是否已经消失. 如果定期更新模块，有时这可能会有点麻烦, 因为您可能需要在前端存储库上重新安装节点模块. 如果有数据库更新，您可能也需要更新这些.

git bisect 自动检出在好的和坏的提交之间的提交. 这里估计的是找到错误提交的一步.

$ git等分好 1cdbd113cad2f452290731e202d6a22a175af7f5
平分:在此之后剩下1个修订需要测试(大约1步)
[ce861e4c6989a118aade031020fd936bd28d535b]添加CSS样式
$ git status
头部分离于 ce861e4
您当前正在分割，从分支'8d4615b'开始.
  (使用“Git等分复位”返回到原始分支)

刷新页面，看看问题是否解决了. 问题仍然存在，所以我们告诉Git这仍然是一个错误的提交. 这次不需要引用提交散列，因为Git将使用您签出的提交. 我们需要重复这个过程，直到Git遍历了所有可能的步骤.

$ git bisect bad
平分:在此之后还剩下0个版本需要测试(大约0个步骤)
[cbf1b9a1be984a9f61b79ae5f23b19f66d533537]添加第二段到页面

刷新页面，我们的问题又消失了，所以这是一个很好的提交:

在这个阶段，Git已经找到了第一个错误的提交:

$ git等分好
Ce861e4c6989a118aade031020fd936bd28d535b是第一个错误提交
提交ce861e4c6989a118aade031020fd936bd28d535b
Author: Ursula Clarke 
日期:1月11日星期二10:52:57 2021 +0100

    Add CSS styles

:000000 100644 0000000000000000000000000000000000000000000000 092bfb9bdf74dd8cfd22e812151281ee9aa6f01a M	css

Now we can use git show 显示提交本身并识别问题:

$ git show ce861e4c6989a118aade031020fd936bd28d535b
提交ce861e4c6989a118aade031020fd936bd28d535b
Author: Ursula Clarke 
日期:1月11日星期二10:52:57 2021 +0100

    Add CSS styles

/css/base.scss b/css/base.scss
index e69de29..26abf0f 100644
--- a/css/base.scss
+++ b/css/base.scss
@@ -1,7 +1,7 @@
 body {
     背景颜色:白色美元;
     margin: 0px;
     行高:20 px;
-颜色:$灰色;
+颜色:红色;
 }

当你完成后，你就可以跑了 Git等分复位 将分支重置为其正常工作状态.

提交的距离越近, Git就越容易找到问题, 但我以前也做过10步，仍然很容易找到错误的承诺. 它不能保证工作，但它在大多数情况下为我找到了问题. 恭喜你，现在你是代码考古学家了!

压缩提交

我以前在一家全球性组织的开源项目中全职工作，我很快就了解到压缩或组合提交是多么重要. 我认为这是一个很好的习惯，即使你的雇主没有要求. 对于以后需要审查和编辑您构建的功能的其他开发人员来说，它特别体贴.

为什么要压缩提交?

• 对于您的存储库的贡献者来说，这更容易阅读. 想象一下，如果你有一个这样的提交列表:
  • 实现旋转滑块
  • 为旋转木马添加样式
  • 添加按钮到旋转木马
  • 修复了IE中carousel的奇怪问题
  • 调整旋转木马的边距

  将这些压缩到一个单独的提交中就容易得多了，比如“将carousel添加到主页”.

• 它鼓励你保持你的提交信息的可理解性和相关性，如果你每次发出拉取请求, 你必须把你的提交压缩成一个. 你见过多少次标题为“WIP”、“登录页面bug修复”或“修复错字”的提交?? 重要的是要有相关的提交名称.g. "修复了#444登录页面-修复了由于缺少$scope函数而导致的闪烁".

您可能不想压缩提交的原因可能是因为您正在处理非常详细和冗长的特性, 并希望为自己保留每日历史记录，以防以后遇到bug. 这样你的特性就更容易调试了. However, 当你把你的特性签入主分支时，你确信它没有bug, 挤压仍然是有意义的.

在这个场景中，我做了5次提交，但它们都与一个特性相关. 我的提交信息也过于密切相关，值得被分开——我所有的提交都是关于这个新特性的页面样式:

$ git log
commit a8fbb81d984a11adc3f72ce27dd0c39ad24403b7 (HEAD -> main)
Author: Ursula Clarke 
日期:1月11日星期二11:16:10 2021 +0100

    Import colors

提交e2b3ddd5e8b2cb1e61f88350d8571df51d43bee6
Author: Ursula Clarke 
日期:1月11日星期二11:15:32 2021 +0100

    Add new color

提交d647ac489ad43b3c6eaea5aceb02b0a7d7e5cf8e
Author: Ursula Clarke 
日期:1月11日星期二10:50:48 2021 +0100

    更改文本颜色

提交c005d9ceeefd4a8d4e553e825fa40aaafdac446e
Author: Ursula Clarke 
日期:1月11日星期二09:59:57 2021 +0100

    Add CSS styles

提交9 e046b7df59cef07820cc90f694fabc666731bd2
Author: Ursula Clarke 
日期:1月11日星期二09:56:28 2021 +0100

    在该页上增加第二段

提交5 aff973577d67393d914834e8af4c5d07248d628
Author: Ursula Clarke 
日期:星期一1月10日16:04:22 2021 +0100

    添加颜色CSS文件和编辑背景颜色

你也可以用 Git merge—squash，但我认为用它更清楚 rebase 因为当您挑选提交时，更容易看到提交描述. If you run a Git merge—squash首先，你必须硬重置你的提交(git reset—hard HEAD~1 )，而且很容易弄不清楚到底需要提交多少次. I find git rebase 为了更直观.

从跑步开始 Git rebase -i——root 命令行上的默认文本编辑器将打开提交列表:

选择eb1eb3c更新主页
选择5aff973添加颜色CSS文件和编辑背景颜色
把第二段添加到页面上
添加CSS样式
更改文本颜色
添加新颜色
pick a8fbb81导入颜色

# Rebase a8fbb81到b862ff2(7个命令)
#
# Commands:
# p, pick =使用commit
# r, reword =使用commit，但是编辑commit消息
# e，编辑=使用提交，但停止修改
# s, squash =使用commit，但合并到之前的commit中
# f, fixup = like "squash"，但是丢弃这个提交的日志信息
# x, exec =使用shell运行命令(剩下的行)
#删除提交
#
# These lines can be re-ordered; they are executed from top to bottom.
#
如果你删除了一行，COMMIT将会丢失.
#
然而，如果你删除了所有的东西，重置将被中止.
#
注意，空提交会被注释掉

您可能只想压缩最后几个提交，在这种情况下，您可以运行 git rebase -i HEAD~3 并展示你最近的三次提交:

选择eb1eb3c更新主页
选择5aff973添加颜色CSS文件和编辑背景颜色
把第二段添加到页面上

# Rebase b862ff2..9e046b7到b862ff2(3个命令)
#
# Commands:
# p, pick =使用commit
# r, reword =使用commit，但是编辑commit消息
# e，编辑=使用提交，但停止修改
# s, squash =使用commit，但合并到之前的commit中
# f, fixup = like "squash"，但是丢弃这个提交的日志信息
# x, exec =使用shell运行命令(剩下的行)
#删除提交
#
# These lines can be re-ordered; they are executed from top to bottom.
#
如果你删除了一行，COMMIT将会丢失.
#
然而，如果你删除了所有的东西，重置将被中止.
#
注意，空提交会被注释掉

现在我们可以将所有提交压缩到第一次提交中，如下所示.

选择eb1eb3c更新主页
添加颜色CSS文件和编辑背景颜色
在这一页上增加第二段

# Rebase b862ff2..9e046b7到b862ff2(3个命令)
#
# Commands:
# p, pick =使用commit
# r, reword =使用commit，但是编辑commit消息
# e，编辑=使用提交，但停止修改
# s, squash =使用commit，但合并到之前的commit中
# f, fixup = like "squash"，但是丢弃这个提交的日志信息
# x, exec =使用shell运行命令(剩下的行)
#删除提交
#
# These lines can be re-ordered; they are executed from top to bottom.
#
如果你删除了一行，COMMIT将会丢失.
#
然而，如果你删除了所有的东西，重置将被中止.
#
注意，空提交会被注释掉

当您保存文件时，Git将打开您的提交消息进行编辑.

#这是3次提交的组合.
#这是第一个提交消息:

Update homepage

#这是提交消息#2:

添加颜色CSS文件和编辑背景颜色

#这是提交消息#3:

在该页上增加第二段

请输入更改的提交消息. Lines starting
带有'#'的#将被忽略，空消息将终止提交.
#
日期:1月13日星期三18:31:28 2021 +0100
#
# interactive rebase in progress; onto b862ff2
#最后一个命令完成(3个命令完成):
添加颜色CSS文件和编辑背景颜色
添加第二段到页面
#没有命令剩余.
你目前正在把分支“main”重新定位在“b862ff2”上。.
#
#要提交的更改:
#新建文件   .gitignore
# new file: css/base.css
# new file: css/base.scss
#新建文件:css/colors.css
#新建文件:css/colors.css.map
#新建文件:css/colors.scss
# new file: css/common.css
# new file: css/common.scss
#新建文件:索引.html
#

在进行rebase时，我们还可以编辑提交描述，使其更易于阅读.

实施新的主页设计. Add .用于Sass文件夹的gitignore文件.

请输入更改的提交消息. Lines starting
带有'#'的#将被忽略，空消息将终止提交.
#

再次保存这个文件，就完成了! 当我们再次查看Git日志时，我们可以看到只有一个干净的提交.

[分离头574ec7e]实施新的主页设计. Add .用于Sass文件夹的gitignore文件.
 日期:1月13日星期三18:31:28 2021 +0100
 10个文件被修改，215个插入(+)
 创建模式100644 .gitignore
 创建模式100644 css/base.css
 创建模式100644 css/base.scss
 创建模式100644 css/colors.css
 创建模式100644 css/colors.css.map
 创建模式100644 css/colors.scss
 创建模式100644 css/common.css
 创建模式100644 css/common.scss
 创建模式100644索引.html
 创建模式100644非常大的文件.txt
成功重置和更新refs/heads/main.
$ git log
commit 574ec7e5d7d7a96427e049cad9806cdef724aedd (HEAD -> main)
Author: Ursula Clarke 
日期:1月13日星期三18:31:28 2021 +0100

    实施新的主页设计. Add .用于Sass文件夹的gitignore文件.

Git Rebase

开发人员通常不愿使用 git rebase 因为他们知道rebase可以用于从代码库中永久删除文件.

As we saw above, git rebase 可以用来保存和整理代码，也可以用来删除——但是如果您真的想永久地从历史记录中删除一个文件，该怎么办呢?

我曾经目睹过这样一个场景:我们开发团队的一名成员意外地向代码库提交了一个非常大的文件. 它是一个更大分支的一部分，所以这个大文件在代码审查中没有被注意到，被错误地签入到主分支中. 每当有人想要重新克隆存储库时，这就成了一个问题——它需要很长时间才能下载! 当然，有问题的文件是不必要的. 如果文件是最后一次提交到主分支，这不会是一个问题——在这种情况下，你可以运行一个硬重置(git reset—hard HEAD~1)，用力推树枝.

Likewise, 如果该文件是给定提交中唯一的更改, 您可以通过运行来删除整个提交 git reset --hard . In our scenario, though, 这个大文件与我们想要保存在历史中的其他代码一起提交, 作为倒数第二份提交.

找到有问题的提交后，使用 git checkout 提交哈希:

$ git checkout ce861e4c6989a118aade031020fd936bd28d535b
注:查看“ce861e4c6989a118aade031020fd936bd28d535b”.

你处于“分离的头脑”状态. 你可以环顾四周，进行实验
更改并提交它们，您可以丢弃在此中所做的任何提交
状态，而不会通过执行另一个签出影响任何分支.

如果您想创建一个新的分支来保留您创建的提交，您可以这样做
通过再次使用-b和checkout命令来执行(现在或以后). Example:

  git checkout -b 

添加CSS样式

删除文件或编辑代码，并保留希望保持完整的代码(或文件).

$ rm非常大的文件.txt
$ git status
头部在ce861e4分离
未提交的更改:
  (use "git add/rm ...“更新将要提交的内容”。
  (use "git checkout -- ..."放弃工作目录中的更改)

	删除:verylargefile.txt

提交时不添加任何更改(使用"git add"和/或"git commit -a")

一定要跑 git add -A 这样被删除的文件就会被暂存，Git就知道要删除它了. Now run Git commit——modify -v Git会要求你编辑提交信息.

After this, run git rebase --onto HEAD main. 这就是你可能遇到一些合并冲突的地方, 这意味着在新提交和旧代码之间存在冲突. Git会要求您解决冲突:

$ git add -A
$ git status
头部分离于 ce861e4
要提交的更改:
  (use "git reset HEAD ..." to unstage)

	删除:verylargefile.txt

$ git commit——modify -v
添加CSS样式
 日期:1月14日星期四14:43:54 2021 +0100
 3个文件被修改，9个插入(+)，2个删除(-)
 创建模式100644 css/common.css.map
 删除模式100644 verylargefile.txt
$ git status
头部与…分离 ce861e4
没有什么要承诺的，工作树干净
$ git rebase -到HEAD ce861e4
首先，回放你的工作...
头对头快进.

如果在文本编辑器中打开该文件, 您将看到Git已经标记出了索引文件的两个版本. 您只需要删除一个或编辑一个，以保留您喜欢的更改.

      

        Toptal是由工程师创建的. 我们都是企业家，都对
        与来自世界各地的顶尖技术人才和令人兴奋的公司合作.
      
<<<<<<< HEAD
      

        Toptal将全球前3%的自由职业人才联系在一起.
      
    
  

=======
    
  

>>>>>>> Add index file

之间的代码 <<<<<<< HEAD 等号行是一个版本，等号和之间的代码 >>>>>>> Add index file 版本是从“添加索引文件”提交. 所以你可以看到一个版本有额外的段落“Toptal连接了世界上前3%的自由职业者人才,，而另一个则不然.

保存编辑后的文件并运行 git add filename followed by Git rebase——继续. 如果没有更改，您也可以运行 Git rebase——跳过. 如果在“大文件”提交和main上的最新提交之间有很多提交，则可能需要一段时间来完成重基.

要有耐心，如果你在一个大型团队中，一定要征求别人的意见! 与编写您正在合并的提交的人进行协商是特别重要的, if possible.

请记住，合并更改与历史记录中的特定提交相关, 而不是你最新的改变. I.e. 如果你正在编辑提交时，你的网站上的文字是Arial, 现在是Verdana, 你仍然应该保留Arial作为字体的历史.

还要注意，如果Git看到一个空格或行结束字符, 它可能导致合并冲突, so be careful!

不仅仅是提交和拉动

Git比许多开发人员想象的更强大. 如果你碰巧要介绍一个新人, 一定要给他们一些关于这些宝贵功能的建议. 它使工作流程更有效率.

希望了解更多关于Git的知识? 看看Toptal吧 Git提示和实践页面.