使用 Git add -p 来玩（和赚钱）

使用 Git add -p 来玩（和赚钱）
Using Git add -p for fun (and profit)

原始链接: https://techne98.com/blog/using-git-add-p/

## 使用 `git add -p` 优化提交在对文件进行大量修改时，创建清晰、原子化的提交可能具有挑战性。简单地使用 `git commit -m "Update stuff"` 感觉不妥，而频繁提交会打断专注力。`git add -p` (或 `--patch`) 提供了一种解决方案，它可以通过交互式暂存 *hunk*（Git 在文件中识别出的单个代码/文本部分）来实现。 `git add -p ` 允许你审查并选择性地暂存每个 hunk，而不是暂存整个文件，可以使用诸如 `y`（是，暂存）、`n`（否，不暂存）、`s`（分割 hunk）、`a`（暂存此 hunk 和剩余 hunk）和 `d`（不暂存此 hunk 和剩余 hunk）等命令。虽然有效，但它最适用于大型项目；较小的文件可能无法从分割中受益。像 LazyGit 这样的工具提供了一个 TUI 界面，可以自动执行这种基于 hunk 的暂存，并且探索交互式变基 (`git rebase -i`) 可以进一步完善提交历史。最终，`git add -p` 鼓励更周全、更易于维护的提交。

这个Hacker News讨论集中在使用`git add -p`（补丁模式）进行更细粒度的提交。原始帖子链接到一篇关于利用此功能进行更好代码管理的文章。用户分享了提供类似功能和改进用户界面的替代工具。许多评论者推荐**tig**（一个基于文本的Git界面）、**JetBrains IDEs**（如Webstorm）、**git-crecord**、**magit**和**lazygit**，用于选择性暂存和提交更改。一个关键点是关于小型、专注的提交与大型、每日结束时的提交之间的争论。一位用户认为，精心构建的Git历史可能会在仓库被重写时丢失，提倡在仓库*内部*进行全面的文档记录，而不是仅仅依赖提交消息来提供开发上下文。

原文

Here’s the problem:

You’re coding, and in flow state, and you make a lot of changes to a single file.

Now you want to commit it, but because there isn’t a single atomic change you have to suck it up and write something terrible like git commit -m "Update stuff", or commit early and often which, while good practice, can be distracting.

This is where git add -p fundamentally changed my workflow, and I feel a bit silly for not knowing about it sooner.

What git add -p actually is

The long version of this Git option is --patch, which opens up an interactive mode for staging “hunks” of text. Hunks are different pieces of code/text that Git has identified in your file.

In other words, when you do git add -p <file> it doesn’t just add the file to staging. Instead, it opens it up and lets you go through different chunks of code to decide what to commit.

Using git add -p

When you first open it up, you’ll get a random assortment of characters at the bottom of your screen. The most important ones (for me) are [y, n, s, a, d].

y accepts the hunk to be staged.
n declines the hunk to be staged.
s tries to split the hunk up into smaller pieces.
a accepts the hunk and any remaining.
d declines the hunk and any remaining.

`s` doesn’t always work as expected

If you have quite a small file, using git add -p sometimes doesn’t really work that great and suggests all of the code to be added. When you try to split it further with s, it doesn’t always work that well.

So keep that in mind. It’s likely better for established and larger projects than one-off scripts.

Further explorations

I’ve heard a lot of people talk about using LazyGit as a TUI frontend. From what I can tell it works by staging these individual hunks by default, essentially giving you an interface for doing git add -p on every change without having to keep re-running git add -p on the same file.

This is what I’m likely going to check out next to help me improve my workflow.

I also have been meaning to understand rebasing properly and git rebase -i to make sure that any commits I make can be maintained more easily in the future.

I hope you found this post useful.

Thanks for reading!