4 ms·

Small frequent commits will limit the need for stash. That's a good practice anyway. The others I'd say could be completely excluded from daily/weekly/yearly u

Small frequent commits will limit the need for stash. That's a good practice anyway. The others I'd say could be completely excluded from daily/weekly/yearly use. If you are using cherry or blame daily then there is probably something wrong :D

simiones 6y ago
Why is small frequent commits a good practice? What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed? Also, cherry is often needed daily in short bursts around releases. Blame is rarer, absolutely, but I don't think you're using your version control to anywhere near its full potential if you don't use blame (and log) while investigating complex bugs.
- chihuahua 6y ago
  One benefit of frequent commits is that it allows you to go back to a recent commit in case your code gets screwed up and you want to undo some recent changes. For example, if you do a search/replace in hundreds of files and make a mistake.
- harrisonjackson 6y ago
  The most important reason imo is making code reviews easier. Enormous PRs = less confidence in merging code on a team. If you are pushing small commits then it is easier for the team to follow the changes and review them. - easier to merge and ship small incremental changes than large ones - easier to revert small commits - better commit messages since you can summarize the smaller change instead of "coded a lot of things" - if you have a messy commit history in a PR you can squash them when merging upstream I'm not sure what your git methodology is but I tend to avoid cherry. We've got a clean production/master branch that we merge develop into on releases. We merge feature branches into develop. Very very rarely we may hotfix something on develop. I don't think I've used cherry in 6 or 7 years on repos with 2-30 active devs. What are you using cherry for daily around releases?
  - simiones 6y ago
    All of those only make sense to me if a commit is a finished work item. If I'm committing just because I want to switch branches or pull, most likely what I'm committing is not meaningful in any way. If I squash later, it doesn't really matter, the reviewer will see one commit anyway, so committing often or not didn't help. And sure, it's easier to ship small features than large ones. But it's harder to follow one complex change as a series of short patches than one big, self-consistent change. So to me, commits should be as often as possible, sure, but that is normally once a day or once every few days for serious features / large bug fixes. I usually want to pull or switch branch much more often than that. And related to release time: typically we have a single main branch that serves multiple projects. When one of these projects is close to a release, they cut off a release branch that is feature frozen, in order to fix any remaining bugs and thoroughly sanitize it. In the meantime, other teams continue merging features into master as they are ready. Bugfixes normally also go into master first, and they are then cherry-picked into the release branch (or branches, if there are multiple releases overlapping). So for us, during this release window, cherry-picking is something that every team member does constantly.
    - harrisonjackson 6y ago
      Interesting - thanks for the extra info. I think the habit of committing more frequently stems from working remotely across different timezones and still making code review a daily habit. It is part of our async communication. If someone hasn't committed code for a few days I'd be concerned they were going down a bad path or getting stuck. I may not even communicate with that team member outside of a PR for the whole week so that's where most of our communication happens if I don't see them in slack or zoom - which would be the case if our work hours don't overlap. But hey! As long as what yall are doing works for you then no worries. No team manages their code the same way - which I'd say is another plus for git.
- HelloNurse 6y ago
  > What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed? "Undo" commits make sense, occasionally, to fix recent incorrect or improper changes that have been already pushed. But the more appropriate way to discard changes is leaving them to rot in the commits of a dead experimental branch, avoiding to merge them into the important branches from which releases are made.

simiones 6y ago

Why is small frequent commits a good practice? What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed? Also, cherry is often needed daily in short bursts around releases. Blame is rarer, absolutely, but I don't think you're using your version control to anywhere near its full potential if you don't use blame (and log) while investigating complex bugs.

chihuahua 6y ago
One benefit of frequent commits is that it allows you to go back to a recent commit in case your code gets screwed up and you want to undo some recent changes. For example, if you do a search/replace in hundreds of files and make a mistake.
harrisonjackson 6y ago
The most important reason imo is making code reviews easier. Enormous PRs = less confidence in merging code on a team. If you are pushing small commits then it is easier for the team to follow the changes and review them. - easier to merge and ship small incremental changes than large ones - easier to revert small commits - better commit messages since you can summarize the smaller change instead of "coded a lot of things" - if you have a messy commit history in a PR you can squash them when merging upstream I'm not sure what your git methodology is but I tend to avoid cherry. We've got a clean production/master branch that we merge develop into on releases. We merge feature branches into develop. Very very rarely we may hotfix something on develop. I don't think I've used cherry in 6 or 7 years on repos with 2-30 active devs. What are you using cherry for daily around releases?
- simiones 6y ago
  All of those only make sense to me if a commit is a finished work item. If I'm committing just because I want to switch branches or pull, most likely what I'm committing is not meaningful in any way. If I squash later, it doesn't really matter, the reviewer will see one commit anyway, so committing often or not didn't help. And sure, it's easier to ship small features than large ones. But it's harder to follow one complex change as a series of short patches than one big, self-consistent change. So to me, commits should be as often as possible, sure, but that is normally once a day or once every few days for serious features / large bug fixes. I usually want to pull or switch branch much more often than that. And related to release time: typically we have a single main branch that serves multiple projects. When one of these projects is close to a release, they cut off a release branch that is feature frozen, in order to fix any remaining bugs and thoroughly sanitize it. In the meantime, other teams continue merging features into master as they are ready. Bugfixes normally also go into master first, and they are then cherry-picked into the release branch (or branches, if there are multiple releases overlapping). So for us, during this release window, cherry-picking is something that every team member does constantly.
  - harrisonjackson 6y ago
    Interesting - thanks for the extra info. I think the habit of committing more frequently stems from working remotely across different timezones and still making code review a daily habit. It is part of our async communication. If someone hasn't committed code for a few days I'd be concerned they were going down a bad path or getting stuck. I may not even communicate with that team member outside of a PR for the whole week so that's where most of our communication happens if I don't see them in slack or zoom - which would be the case if our work hours don't overlap. But hey! As long as what yall are doing works for you then no worries. No team manages their code the same way - which I'd say is another plus for git.
HelloNurse 6y ago
> What is to be gained from committing a change to a file, then a commit to undo the previous one if you decide the change wasn't useful/needed? "Undo" commits make sense, occasionally, to fix recent incorrect or improper changes that have been already pushed. But the more appropriate way to discard changes is leaving them to rot in the commits of a dead experimental branch, avoiding to merge them into the important branches from which releases are made.