3 ms·

I make a point never to commit broken code anyway. If a series of changes have to be together to not break, I put them all in one commit. And for organization’s

I make a point never to commit broken code anyway. If a series of changes have to be together to not break, I put them all in one commit. And for organization’s sake, commits could still be tagged by ticket That doesn't mean an entire feature has to go in one commit (usually). Often a feature is made up of a series of non-breaking changes that can be layered one at a time, if appropriate.

sp332 5y ago
That negates one of the major advantages of committing code, which is having a regular backup of your work.
- ehaughee 5y ago
  My team makes several commits locally, then rebases, squashes, and pushes the squashed commit to the trunk which has CI. This maintains a local, regular backup of your code and collects features into single commits for the trunk which are easily revertable if found to be problematic. This flow will not work for everyone, but it works very well for us (a team of 8 at a FAANG company). Edit: Rereading your comment, I suspect you mean non-local backups. Our organization has a special remote only visible to you and those you allow for pushing code you'd like to backup off of your box.
  - sp332 5y ago
    That sounds like feature branches but with more steps and worse. You can't share your unfinished work non-locally, for one thing. And it has none of the advantages of CI because you still have infrequent large merges.
SAI_Peregrinus 5y ago
How about with multiple repos, across multiple systems? Eg. embedded device with 4-week test cycles, backend server with CI/CD, frontend site with CI/CD, and upstream vendor contribution PR(s), and where the data fees for firmware updates to the set of all customer embedded devices run into the hundreds of thousands of dollars? You can't get them all in one commit then. Even with a monorepo (not contributing back to upstream) it'd be an utterly massive commit.
gotts 5y ago
> If a series of changes have to be together to not break, I put them all in one commit. I'm sorry but it hurts just to read this. Just No.
- jwdunne 5y ago
  Please could you expand? Without substance, there’s nothing here that defends your position.
  - majewsky 5y ago
    Going back through history to find where a bug was introduced usually happens on the commit level (e.g. git-bisect only operates on commits, naturally). Once you find the commit that introduced the bug in question, it will be immensely easier to hunt down the bug within the commit if the commit is 10 or 50 lines long instead of 500 or 1000.
erik_seaberg 5y ago
As a reviewer I really want a series of commits each making closely related changes that are easy to understand. Squashing tends to make giant diffs that replace almost every line, and you almost have to reverse-engineer to figure out what’s actually supposed to be different.

sp332 5y ago

That negates one of the major advantages of committing code, which is having a regular backup of your work.

ehaughee 5y ago
My team makes several commits locally, then rebases, squashes, and pushes the squashed commit to the trunk which has CI. This maintains a local, regular backup of your code and collects features into single commits for the trunk which are easily revertable if found to be problematic. This flow will not work for everyone, but it works very well for us (a team of 8 at a FAANG company). Edit: Rereading your comment, I suspect you mean non-local backups. Our organization has a special remote only visible to you and those you allow for pushing code you'd like to backup off of your box.
- sp332 5y ago
  That sounds like feature branches but with more steps and worse. You can't share your unfinished work non-locally, for one thing. And it has none of the advantages of CI because you still have infrequent large merges.

SAI_Peregrinus 5y ago

How about with multiple repos, across multiple systems? Eg. embedded device with 4-week test cycles, backend server with CI/CD, frontend site with CI/CD, and upstream vendor contribution PR(s), and where the data fees for firmware updates to the set of all customer embedded devices run into the hundreds of thousands of dollars? You can't get them all in one commit then. Even with a monorepo (not contributing back to upstream) it'd be an utterly massive commit.

gotts 5y ago

> If a series of changes have to be together to not break, I put them all in one commit. I'm sorry but it hurts just to read this. Just No.

jwdunne 5y ago
Please could you expand? Without substance, there’s nothing here that defends your position.
- majewsky 5y ago
  Going back through history to find where a bug was introduced usually happens on the commit level (e.g. git-bisect only operates on commits, naturally). Once you find the commit that introduced the bug in question, it will be immensely easier to hunt down the bug within the commit if the commit is 10 or 50 lines long instead of 500 or 1000.

erik_seaberg 5y ago

As a reviewer I really want a series of commits each making closely related changes that are easy to understand. Squashing tends to make giant diffs that replace almost every line, and you almost have to reverse-engineer to figure out what’s actually supposed to be different.