[rom1v]

> We therefore squash and merge our feature branches onto dev when a PR is opened and merged. Regardless of how many commits a feature branch has, once it is merged, all the commits are squashed into a single commit

So several steps to implement a feature are mixed up into a single change :/ That looks awful to me, when you need to read the history to understand how and why.

[josephg]

The problem in my mind is that we’re overloading what a “commit” means. There’s two meanings: either it’s a description of what happened, by some author, at some point in history. Or it’s an atomic feature being added to the codebase.

Commits are the first thing by default. If you squash and rebase them, they become the second thing (feature changes). But in doing so you throw out information about the original history of those changes.

This has always seemed silly to me. Git should just be changed to support both work flows. Keep commits as-is but let me mark a range of commits as being part of feature X, and let me browse the repo from the perspective of those larger feature objects. Or make it so merge / squash commits still reference the individual commit sequence, so I can see what happened in more detail if I want to.

[bonzini]

It already does, using "git merge --no-ff" and "git log --first-parent".

[reilly3000]

I’m an imperfect human, but I don’t always see the value in having 5 commits that say “fixes lint error” and another few “fixes typo” in the git log for every feature branch. Perhaps there is a middle way.

[ByThyGrace]

> I don’t always see the value in having 5 commits that say “fixes lint error”

That's a problem I avoid by spicing the log with commit messages from http://whatthecommit.com/ ! :)

[xorcist]

There are also technical reasons to separate commits. Moving files is best done in a separate commit, otherwise --follow might not work as you might expect. Squashing that together with changes might very well break that logic.

Always rebase before pushing for review, just don't squash everything. One would hope that much would be self evident.

[rom1v]

A PR may contain several distinct meaningful related commits, this has nothing to do with typo fixes.

But even then, when you want to revert or cherry-pick a commit on another branch, you don't want random unrelated changes (which increase the risk of conflicts).

Also, a single commit containing 10 squashed commits doesn't help for git bisect.

[ivalm]

Would you be ok with history rewriting in feature branch prior to merge? Seems like potentially best of both worlds.

[rectang]

I do minor history rewrites on my feature branches all the time.

1. Fix typo or other small nit.

2. `git add -p` to add only the small change.

3. `git commit -m fixer`

4. `git stash`

5. `git log --oneline main..` and copy the SHA of the commit I want to fix.

6. `git rebase -i SHA~`

7. In the text editor launched by `rebase`, move the "fixer" commit after the one I want to modify.

8. For the `fixer` commit, change "pick" to "fixup". Save and quit, allowing the rebase to complete.

9. `git stash pop`

This works most of the time, so long as the nit I want to fix isn't too far back in history. For those nits that aren't easy to fix with the workflow above, I just create an ordinary commit and leave it. It's annoying to have 5 "fixes lint error" commits in every feature branch, but it's fine to have them every once in a while.

[vtbassmatt]

`git commit --fixup` and `git rebase --autosquash` automate a bit of the drudgery for this workflow. Sharing because I just got introduced to them recently.

[dakom]

The middle way would be if git tracked branches historically.

That would fix a lot of problems imho

[KronisLV]

I guess that depends on how detailed the commit messages are and how many changes they have, which will be affected both by the specifics of the project and the people in it.

Consider the following:

  [8 files changed] ISSUE-541 added DB migrations and repositories for the new functionality of managing Foos
  [2 files changed] ISSUE-541 refactor the DB migrations to do Bar before creating one of the views because of it breaking otherwise due to Baz
  [11 files changed] ISSUE-541 refactor old services to use the new Foo functionality, because it should be more consistent than using native queries with complex SQL
  [3 files changed] ISSUE-541 fix problems with fetching data in some of the old services, because edge cases were not covered, add unit tests to cover this functionality
  [7 files changed] ISSUE-541 add services for managing Foos, though they will only be used in ISSUE-544, add comments about this
  [20 files changed] optimize the imports in the Foos package and remove unused code (should automate this later)

And then the following:

  [3 files changed] DB migrations
  [1 file changed] refactor
  [4 files changed] refactor
  [1 file changed] fix code, add tests
  [2 files changed] services
  [6 files changed] formatting

In one of the cases, the changes are larger and therefore more meaningful descriptions of what each commit does are probably a good thing - if the refactoring of code would break anything that wouldn't be immediately apparent but would later be detected, being able to click in the commit in the IDE history and see what exactly was changed as a part of it could be pretty useful!

Whereas in the other case, there are fewer files changed, so the pattern that i've seen emerge is that most people won't care much about detailed commit messages, because of which it is no longer that useful.

Of course, i've also seen people (the majority of my coworkers, though it depends on the company) not really care about commit messages or even making smaller atomic commits at all, thus a feature branch could look like the following:

  [28 files changed] ISSUE-541
  [11 files changed] refactoring

Then again, the majority of people in my current company also always leave merge request descriptions completely empty and expect you to figure out what the code does by its contents alone in the diff, without providing any context or further considerations. Personally, i'm against this and while i don't want to sour our relationships by nagging about it, personally i always write out a bit of information about what each feature branch accomplishes, as well as even include a few images or GIFs.

That has made my own life much easier when something seemingly breaks 9 months down the line and no one has any idea why, whereas i can just look at the merge request for the offending code and see all of the charts and explanations i need.

Personally, i think that the closer your documentation (of any sort) is to your code, the better the end results.

[Izkata]

> In one of the cases, the changes are larger and therefore more meaningful descriptions of what each commit does are probably a good thing - if the refactoring of code would break anything that wouldn't be immediately apparent but would later be detected, being able to click in the commit in the IDE history and see what exactly was changed as a part of it could be pretty useful!

This has happened to me when tracking down bugs a whole bunch of times in our various svn codebases, where commits can't be squashed like in git. Once it even happened in a linting commit when someone accidentally messed up indentation in python.