git commit的做法更好？ [英] What git commit practice is better?

问题描述

我真的相信，在一个问题上有一个承诺是一个好的做法。我确信我在最佳实践这样的文章中的某个地方阅读过它。

因此，我的工作流程如下：

• 问题，我使用 git checkout -b new-issue 创建一个新的本地分支。


• 提交所有更改。有时这涉及到很多提交。


• 完成后，I squash 提交和 rebase 到当前专题分支。


• 如果出现问题，我可以 git revert 提交，找到bug，修复它，然后在专题分支中提交新补丁。我不会更改远程存储库的历史记录。

但是今天，我惊讶地听到以下工作流程：

• 为新问题创建新分支。


• 提交所有内容。


• 使用 merge --no-ff 来合并问题分支和专题分支（所以我们会有merge-commit，我们可以如果出现问题，我们可以使用 git bisect 来查找错误。
/ li>


---

根据第一种方法，我们将拥有一个干净的git历史记录，根据第二种方法，我们将有一个非常混乱的历史，有很多丑陋的，不必要的合并和提交的公正一个问题。但是，我们可以使用 git bisect 来查找错误。 （也许这对重构更好？）

---

• 有什么优点和缺点你看到两种方法？

在实践中，你有没有实际使用 git bisect 来查找错误？ （我没有...） 很大程度上是个人品味问题......只能解释我的口味（并给出一点理由）。



我倾向于保持个人承诺，即使在他们只是修复愚蠢的错别字。任何历史重写都会创建前所未有的提交，因此保证永远不会被测试。此外，当稍后提交bug时，最小的提交使得 git bisect 非常有用。更好的是能够将它缩小到几个变化的行，而不是一周的工作，一起压扁。





如果一个开发分支弄脏了历史，我会清理（最低限度地说，也就是说，还原的提交从未发生过，像空白或变量重命名这样的常规修复可能会在早期应用，有些重新排序将相关更改放在一起）。承诺仍然很小，很少被压扁。这个清理我主要是增量式的。然后我把清理好的分店与官方分店合并（或重新分店）。


I truly believe that to have one commit on one issue is a good practice. I'm sure I read it somewhere in an article like "Best practices".

As such, my workflow has been the following:

• For a new issue, I create a new local branch with git checkout -b new-issue.
• Commit all changes into it. Sometimes this involves lots of commits.
• When done, I squash the commits and rebase them into current thematic branch.
• If something goes wrong, I can git revert the commit, find the bug, fix it, and commit new patch into the thematic branch. I won't change the remote repository’s history.

But today, I was surprised to hear the following workflow:

• Create new branch for the new issue.
• Commit everything into it.
• Use merge --no-ff to merge the issue branch with thematic branch (so we’ll have "merge-commit" that we can revert).
• If something goes wrong, we can use git bisect to find the bug.

---

According to the 1st approach, we’ll have a clean git history, and no idea about overhead branches used during development.

According to the 2nd approach, we’ll have a very messy history, with a lot of ugly, unnecessary merges and commits for just one issue. However, we can use git bisect to find bugs. (Perhaps this is better for refactoring?)

---

• What pros and cons do you see for both approaches?

• Which approach do you use, and why?

• In practice, have you actually used git bisect to find bugs? (I haven't…)

解决方案

In the end, it is largely a personal taste issue... can only explain my taste (and give a bit of justification for it).

I tend to keep the individual commits around, even when they are just "Fix dumb typos". Any "history rewriting" creates commits that never before existed, so are guaranteed never to have been tested. Besides, minimal commits make git bisect immensely useful when a bug surfaces later. Better to be able to narrow it down to a few changed lines than to a week's work, squashed together.

If a development branch gets a mess of a history, I clean it up (minimally, i.e., reverted commits just never happened, general fixes like whitespace or variable renamings might get applied earlier, some reordering to place related changes together). Commits still stay small, are rarely squashed. This cleanup I do incrementally mostly. Then I merge (or rebase) the cleaned up branch with the "official" one.

这篇关于git commit的做法更好？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！