基于主干开发的 Git 技巧

基于主干的开发是一种源代码分支模型，旨在降低代码集成和交付风险。如果成功实施，它有助于缩短交付生产价值的交付周期。

在这篇文章中，我不会关注基于主干开发的好处，而是尝试概述一些示例，说明如何利用 git 在实现这种分支模型时获得更好的结果。

git pull -r

在基于主干的开发中，当你在自己的分支上实现小功能时，主分支（或主干）可能会经常更新。为了保持同步，请确保你的变更集始终应用到最新版本的主分支上：

1. 确保您位于功能分支上：

$ git branch
master
* my-awesome-feature

2a. 现在让我们在本地分支上的 master 上重放我们的更改：

$ git pull -r origin master

此命令确保在重新定基之前从源获取最新的更改。

2b. 如果你想更好地控制你的提交，另一个选择是以交互方式进行 rebase：

$ git pull --rebase=interactive

这将列出将在本地分支上的 master 之上应用的所有提交：

pick 1ff6000 Brilliant commit
pick f144bad Even better commit
pick dc69aa1 Average commit

您可以按照编辑器中包含的说明来微调您的提交列表，并可能进行一些更改，例如压缩最后两次提交。

pick 1ff6000 Brilliant commit
pick f144bad Even better commit
fixup dc69aa1 Average commit

注意：修复将丢弃正在修复的提交的提交消息

暂时搁置您的更改

你可能已经在本地开始开发新项目，这时团队中有人需要你审核他们的拉取请求。为了不丢失进度，你必须确保在签出要审核的更改之前，将进度存储在某个地方。

git stash

git-stash通过在本地存储您的更改来帮助您实现这一点。

$ git stash -u -m"Exploring a possible AI-based blockchain compiler 🤯"

-u 开关确保未跟踪的文件也能被存储，这非常方便。
存储不需要消息，但我发现它在恢复暂停的工作时非常有用。

现在，您可以通过执行以下操作来确保您的更改已被存储：

$ git stash list
stash@{0}: On ai-spike: Exploring a possible AI-based blockchain compiler 🤯

现在您可以检出其他人的代码了。当您准备返回之前的工作时，您可以：

$ git stash pop

它会自动应用最新的存储更改并将其从存储集合中删除（如果没有发生冲突，否则一旦解决冲突，您将必须手动 git stash drop 它）。

或者，您可以使用

$ git stash apply

其作用与 pop 相同，但不会自动从 stashes 集合中删除更改。

这两个命令都接受存储引用（以 的形式stash@{<index>}），您可以使用它来取消存储特定的更改。

git commit -m"WIP"

另一种选择，特别是当您需要将临时更改推送到原点时（可能是因为您想从另一台机器完成工作），可能会暂时提交所有内容，然后稍后再回来清理分支历史记录。

您可以做的是：

$ git branch
* my-temp-branch
master
$ git add --all
$ git commit -m"[WIP] Current progress on AI-based blockchain compiler 🤯"

在这种情况下，我喜欢在我的提交前面加上一个常见标签，例如 WIP（正在进行的工作）。

当您准备好恢复工作时，您可以执行以下操作：

$ git checkout my-temp-branch
$ git reset HEAD~1 # assuming you've stored everything in the last commit

reset 将恢复您当前的工作目录状态到提交之前的状态，保留 WIP 提交的修改（除非您指定--hard）。

git rebase

尽管我已经提到了 rebase 作为拉取部分的一部分，但在这里我将使用纯 git rebase 命令来涵盖稍微不同的情况。

如果您认为当前功能分支的提交历史记录需要稍微清理一下，git rebase 可能会派上用场。

有时，你可能会将几个提交合并成一个，或者重新排序其他几个提交，以使整个分支历史记录更加清晰。所有这些都可以通过使用 轻松实现git rebase --interactive。

假设你想查看自 master 分支以来你分支上的所有 7 条提交。（专业提示：如果你不记得有多少条提交与 master 分支不同，你可以这样做：git log master...这将仅显示相关的提交）

$ git branch
* lovely-branch
master
$ git rebase -i HEAD~7

您配置的编辑器将打开，其中有 7 个提交等待处理：

pick 30d730d It begins...
pick abd7151 Made some progress...
pick ba722fd Tests pass!
pick 06566b7 Added one more test case
pick 6bc75a2 Refactored class names
pick cb81607 Added docs
pick 2f9b368 Fixed typo in docs

我们可以如下改写历史：

pick 30d730d It begins...
sqaush abd7151 Made some progress...
fixup ba722fd Tests pass!
fixup 06566b7 Added one more test case
reword 6bc75a2 Refactored class names
reword cb81607 Added docs
fixup 2f9b368 Fixed typo in docs

第一次压缩后，我们会被要求修改提交信息：我们可以指定一些更具描述性的内容，例如“新的编译目标：WebAssembly”。后续的fixup提交信息将丢失。
然后，第一个 reword 项会要求我们指定一条新的提交信息：“将 WASM* 类重命名为 WA* 类”。最后，最后一个 reword 项将变为：“为 WebAssembly 目标添加了缺失的文档部分”。

b981780 New compilation target: WebAssembly
16cde4c Renamed WASM* classes to WA* classes
451eaf2 Added missing documentation section for the WebAssembly target

更清晰的分支历史。

使用--force（带租赁）

如果您的分支在重写其历史记录之前已经被推送到远程，那么您将必须明确地覆盖它。

$ git push --force-with-lease lovely-branch:lovely-branch

如果符合预期（例如，它与原始的本地引用匹配），这将覆盖当前分支的远程历史记录。

以下是更详细的解释：

“--force-with-lease除非分支状态符合我们的预期，否则拒绝更新；也就是说，上游分支尚未更新。实际上，这是通过检查上游引用是否符合我们的预期来实现的，因为引用是哈希值，并且会将父级链隐式编码到它们的值中。”

不幸的是，--force-with-lease如果您（或您的 IDE）在后台进行提取，将无法保护您，因为 git 将无法检测到与预期的远程引用的任何差异。

一般来说，在基于主干的开发中，其他人与你并行开发同一功能分支的可能性非常低，甚至完全不存在。这是因为在这种分支模型中，你每次只能处理一些小的变更，这使得所有开发人员可以同时处理不同的工作（因此也就有了不同的分支）。

结论

我介绍的命令是我通常的开发工作流程的一部分。希望这篇概述对您有所帮助，并请留下反馈，让我知道您如何使用它们git来实现基于主干的开发。

如果您想了解更多有关软件工程实践的信息，请在 Twitter 上关注我。

照片由Dries Augustyns在Unsplash上拍摄

最初发表于Clubhouse.io