与 Git 中的新功能混合进行重构的最佳工作流程是什么？
我一直使用 Git 作为源代码管理工具。 现在我的工作流程很简单：
- 考虑一个最小的新功能/重构
- 代码，它
- 检查差异
- 使用 HEAD提交
我想改进这个工作流程，使其更加灵活。 原因是我已经遇到过几次以下情况，我认为这是典型的情况：
提交后，我开始修改工作目录以添加新功能。
我编码了一会，设此时工作目录的状态为A。 这里重要的是，状态 A 工作目录尚未准备好提交，因为新功能尚未完成。
此时我意识到最好先进行重构。 承认吧，有时在代码修改过程中重构的需要变得很明显。
现在我需要重新从 HEAD 开始，先进行重构。 但我不想丢失代码 HEAD -> 的修改 状态 A. 所以基本上我需要：
- 在上次提交后尚未更改的工作目录副本中进行重构 提交
- 它
- 合并我已启动的新功能的工作并在工作目录是时停止它在状态 A 中
- 的工作
- 完成新功能提交
，我相信这是分支可以帮助我的地方，但我在计算正确的 git 命令时遇到了问题。 我感到困惑的是，当工作目录在提交后更改时，我需要创建一个分支，并且我不知道处理此问题的正确方法。
用 Git 命令描述上述工作流程的正确方法是什么？
I've been using Git as source code management tool.
For now my workflow is simple:
- think about a minimal new feature/refactoring
- code it
- review the diff with HEAD
- commit
I would like to improve this workflow, by making it more flexible. The reason is that I've encountered the following situation a couple of times, which I think is a typical one:
After a commit, I'm starting to modify the working directory in order to add a new feature.
I code for a while, let the state of the working directory be A at this moment. The important thing here is that is state A the working directory is not ready to be committed, because the new feature is not completed yet.
At this point I realize that it would be better to perform a refactoring first. Admit it, sometimes the need of a refactoring becomes obvious in the process of code modification.
Now I need to start again from HEAD and do the refactoring first. But I don't want to lose the modification of code HEAD -> state A. So basically I need to:
- do the refactoring in a copy of the working directory that is not altered yet after the last commit
- commit it
- merge the work on the new feature that I've started and stopped it when the working directory was in state A
- complete the work on the new feature
- commit it
I believe this is where branching can help me, but I'm having issues figuring the correct git commands. I'm confused by the fact that I need to create a branch when the working directory is altered after a commit and I don't know the correct way do deal with this.
What's the correct way to describe the above workflow in terms of Git commands?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你想要 git stash。 当您的工作目录处于未准备好提交的中间状态时，请运行“git stash”或“git stash save“一些文本””。 这会将您的工作目录带回 HEAD。 现在进行更改并提交。 然后运行“git stash pop”，您之前的中间工作将被合并到工作目录中。 你可以有多个储藏室； 将它们列出为“git stash list”。 （“某些文本”将识别它们。如果您不提供任何消息，则使用最后的提交日志。）
另请参阅“git add --patch”和 git add“--interactive”
You want git stash. When your working directory is in an intermediate state that you are not ready to commit, run 'git stash' or 'git stash save "some text"'. This will take your working directory back to HEAD. Now make a change and commit. Then run 'git stash pop' and your previous intermediate work will be merged into the working directory. You can have multiple stashes; list them gith 'git stash list'. (The 'some text' will identify them. If you provide no message, the last commit log is used.)
See also 'git add --patch' and git add '--interactive'
当您开始一项新功能时，创建一个新分支并在那里工作。 当您认为需要重构未处理的代码时，请切换回 master（或另一个专用分支）并执行此操作。 完成后，将重构分支合并回主分支。 然后在更新的主分支之上重新建立你的功能分支。
When you start a new feature, create a new branch, and do work there. When you think you need to refactor code that you're not working on, switch back to master (or another dedicated branch) and do it. When you're done, merge the refactoring branch back into master. Then rebase your feature branch on top of the updated master.
我相信 git stash 就是您正在寻找的。
git stash is what you're looking for, I believe.