<< Git conflict Git Squash >>

Git Rebase

Rebasing是一个在另一个基础行程之上重新应用提交的过程。它用于将来自不同分支的一系列提交应用于最终提交。它是git merge命令的替代方法。这是一个线性的合并过程。

在Git中，术语rebase被称为将一系列提交或移动到新的基本提交中的过程。重定基非常有益，它可以在功能分支工作流的环境中可视化该过程。

在合并分支之前先重定基，这是很好的做法。

通常，它是git merge命令的替代方法。合并始终是向前更改的记录。相对而言，rebase是git中令人信服的历史记录重写工具。它一一合并不同的提交。

假设您已经在master分支中进行了3次提交，在名为test的其他分支中进行了3次提交。如果将其合并，则它将一次合并所有提交。但是，如果您重新设置基础，则它将以线性方式合并。考虑下面的图像:

上面的图像描述了git rebase的工作方式。 master分支的三个提交与test分支的提交线性合并。

合并是集成分支的最直接方法。它在两个最新的分支提交之间执行三向合并。

如何重新设置

在功能分支(测试分支)上进行某些提交而在主分支中进行某些提交时。您可以将任何这些分支作为基准。使用git log命令跟踪更改(提交历史记录)。签出到要重新设置基准的所需分支。现在，按如下所示执行rebase命令:

语法:

$git rebase <branch name>

如果分支中有一些冲突，请解决它们，然后执行以下命令以继续更改:

$ git status

它用于检查状态，

$git rebase--continue

以上命令用于继续所做的更改。如果要跳过更改，可以跳过以下操作:

$ git rebase--skip

重新定标完成时。将资源库推到原点。考虑以下示例以了解git merge命令。

假设您正在使用分支 test2 。您现在位于test2分支上，并对项目的文件 newfile1.txt 进行了一些更改。

将此文件添加到存储库:

$ git add newfile1.txt

现在，提交更改。使用以下命令:

$ git commit-m "new commit for test2 branch."

输出将如下所示:

[test2 a835504] new commitfor test2 branch
 1 file changed, 1 insertion(+)

将分支切换为主节点:

$ git checkout master

输出:

Switched to branch 'master.'
Your branch is up to date with 'origin/master.'

现在您在master分支上。 newfile.txt 说，我已将更改添加到我的文件中。以下命令用于将文件添加到存储库中。

$ git add newfile.txt

现在提交文件以进行更改:

$ git commit-m " new commit made on the master branch."

输出:

[master 7fe5e7a]  new commit made on master
 1 file changed, 1 insertion(+)
HiMaNshU@HiMaNshU-PC MINGW64 ~/Desktop/GitExample2 (master)

要检查日志历史记录，请执行以下命令。

$ git log--oneline

输出:

如我们所见日志历史记录，master分支中有一个新的提交。如果我想重新建立test2分支的基础，该怎么办？请参阅下面的rebase分支方案:

Rebase分支

如果我们有来自不同分支的许多提交，并且希望将其合并到一个分支中。为此，我们有两个选择，要么可以合并它，要么对其重新设置基础。重新设置分支的基础是很好的。

在上面的示例中，我们已提交到master分支，并希望将其基于test2分支。让我们看下面的命令:

$ git checkout test2

此命令将使您从主服务器切换到test2分支。

输出:

Switched to branch 'test2.'

现在您在test2分支上。因此，您可以使用master分支为test2分支重新设置基础。参见以下命令:

$ git rebase master

此命令将重新建立test2分支的基础，并显示为正在应用: test2分支上的新提交。考虑以下输出:

输出:

Git交互式Rebase

Git有助于进行交互式Rebase；它是一个强大的工具，它允许对现有提交进行各种操作，例如编辑，重写，重新排序以及更多操作。 Interactive Rebase只能在当前签出的分支上进行操作。因此，请在边栏上设置本地HEAD分支。

可以使用rebase命令调用Git交互式rebase，只需在 -i 中输入rebase命令即可。这里的" i "代表互动。该命令的语法如下:

语法:

$ git rebase-i

它将列出所有可用的交互式选项。

输出:

在给定输出之后，它将打开带有可用选项的编辑器。考虑以下输出:

输出:

当我们执行git Interactive rebase命令时，它将打开具有以上输出的默认文本编辑器。

其中包含的选项如下所示:

Pick Reword Edit Squash Fixup Exec Break Drop Label Reset Merge

以上选项通过git-rebase执行其特定任务。让我们简要地了解每个选项。

Pick (-p):

选择此处表示已包含提交。提交的顺序取决于变基期间的pick命令的顺序。如果您不想添加提交，则必须删除整行。

Reword (-r):

改写与pick命令非常相似。 reword选项暂停了rebase过程，并提供了更改提交消息的机会。它不会影响提交所做的任何更改。

Edit (-e):

编辑选项可用于修改承诺。修改方式是，可以完全添加或更改提交。我们还可以在rebase继续命令之前进行其他提交。它允许我们将大型提交拆分为较小的提交。此外，我们可以删除一次提交中所做的错误更改。

Squash (-s):

通过压扁选项，您可以将两个或多个提交合并为一个提交。它还允许我们编写新的提交消息来描述更改。

Fixup (-f):

类似于壁球命令。它丢弃了要合并的提交消息。较早的提交消息用于描述这两个更改。

Exec (-x):

exec选项允许您运行

Break (-b):

break选项将重新启动停在正确位置。

Drop(-d):

它将在以后继续使用' git rebase--continue '命令重新设置基础。

drop选项用于删除提交。

Label (-l):

标签选项是

Reset (-t):

重置选项用于重置

GitMerge vs. Rebase

对于git用户而言，何时使用合并命令以及何时使用rebase是最常见的令人困惑的问题。这两个命令都是相似的，并且都用于合并存储库中不同分支的提交。

在共享分支中不建议使用重新存储，因为重新存储过程会创建不一致的存储库。对于个人而言，重新合并比合并更有用。如果要查看完整的历史记录，则应使用合并。合并跟踪整个提交的历史记录，而重新基准则重写新的提交历史。

Git rebase命令被称为git merge的替代方法。但是，它们有一些主要区别:

Git Merge	Git Rebase
合并会在合并时创建最终提交。	Git变基在变基时不会创建任何提交。
它将所有提交合并为一个提交。	它创建了一条线性的提交轨迹。
它创建了一个图形化的历史记录，可能难以理解。	它创建了易于理解的线性历史记录。
合并两个分支是安全的。	Git的"变基"处理了严重的操作。
可以在公共和私人分支机构上进行合并。	在公共分支机构上使用基础调整是错误的选择。
合并将功能分支的内容与主分支集成在一起。因此，更改了master分支，并且特征分支历史记录保持一致。	重新设置master分支可能会影响功能分支。
合并会保留历史记录。	Rebasing重写历史记录。
Git合并会立即显示所有冲突。	Git rebase一对一呈现冲突。

找工作要求35岁以下，35岁以上的程序员都干什么去了？

长久以来，一直有一个问题困扰着技术人——如何打破“程序员的35岁职业魔咒”，这一天迟早会到来，或早或晚。

或许是选错了行业，程序员薪水虽高，但光鲜的外表下，背后的苦衷只有自己知道。三十多岁本该是一个人事业的黄金期，但技术变化日新月异，行业竞争异常残酷，对一个企业来说，永远有比你更年轻、劳动成本更低的人可以选择，这让你的中年危机提前到来。破局的智慧可以看看这本书！>>

<< Git conflict Git Squash >>

昵称：邮箱：