7 ms·

Strange policy about commits — why just not push at night or during weekends? Why's everyone not working on branches?

by dchest 7y ago

dahart 7y ago
> Strange policy about commits — why just not push at night or during weekends? Why's everyone not working on branches That is what I’m saying. The policy is avoid pushes to master. My policy does apply to branches too once there are more than a few people in the branch. Lots of people do work in branches, but everywhere I’ve worked, plenty of people skip branching when they’re making what they think are “small” changes. And some places I’ve been, the team has decided on a policy to skip branches & merges for single commit changes due to the history noise it causes. The policy is to avoid breaking changes being committed to master when people aren’t around to notice & fix it.
- stinkbug9o 7y ago
  You’re describing merges, not commits, or pushes to remotes. One can commit and push to branches all day. Merging them to master without a heads up is a bad idea, except where teams have implemented a process that can handle it
  - inlined 7y ago
    Many of us do a “squash merge” (use git rebase to compress to meaningful points in a CR and again before merging to master or feature branches). This creates a clean history at the expense of not being able to stalk others work at high granularity or get as large a score on github’s tracker.
    - testvox 7y ago
      Git rebase interactive with fixup or squash will combine the commits into the first one. So the timestamp will still be somewhat reflective of when work is done (on average).
      - inlined 7y ago
        Though I wouldn’t be surprised if there is at least some biasing. E.g. first commits happening relatively soon after regularly scheduled scrum meetings. At least if they’re the type of developer who checkpoints after incremental changes.
      - mandelbrotwurst 7y ago
        Are you sure? It seems fairly likely to me that the average time of day that someone makes the initial commit on a new branch would be quite different from the average time of day that they make commits generally. Am I misunderstanding?
    - MaxBarraclough 7y ago
      I'm not convinced that a 'clean history' beats a richer more fine-grain history. There's a reason frequent small commits are generally thought to be the way to go.
      - hoten 7y ago
        except of my dozens or so commits to a feature branch, most of which are "update" or "fix test" or "oops forgot edge case". But for the one squash commit, it's "some-feature-tag: nice description of the changes (#relevant-pr)". and there's no way I'm going to write more than one nice commit message for a branch. You can still get the fine-grained commits if you keep your merges focused on one thing.
        MaxBarraclough 7y ago
        > You can still get the fine-grained commits if you keep your merges focused on one thing. Right. This is what Git Flow does. Best of both worlds.
    - hinkley 7y ago
      Stalking other workers at high granularity is sometimes the only way I have to figure out what was going through their head (or indeed, my head 2 years ago) when they wrote this... very interesting logic. The biggest WTF programmer I work with squashes all of his commits. So every commit is 100-400 lines of Rube Goldbergian majesty.
  - dahart 7y ago
    > You’re describing merges, not commits, or pushes to remotes. Both merges and commits can be pushed. I’m not exactly sure what distinction you’re trying to make. Also, btw, I’m using git terminology, but not everyone uses git. I’m including my experience on teams that use Perforce, for example. > One can commit and push to branches all day. Merging them to master without a heads up is a bad idea. Yeah, right, exactly. You agree with me. My policy is about putting anything new in the master branch during off hours, because breaking changes that evade the tests may not get fixed until work hours, and prevent other people from working at night or over the weekend.
    - kragen 7y ago
      The article is about the times of day Git commits were made, not the times of day they were pushed, nor the times of day people used other source-control systems like Perforce. You said, "I’d be very cautious about assuming that commit time has anything to do with work time," citing your own policy of not pushing at night as an example of how "commit time" may not have anything to do with work time. Now you're saying, "My policy is about putting anything new in the master branch during off hours," which is to say, it's about pushes, not commits. This means that your original top-level comment is completely irrelevant to the article you are commenting on, which is unfortunate, since it's the top-voted comment on the article. You should edit the top-level comment to reflect that fact, or, if that's not possible, add a second-level comment retracting it.
      - dahart 7y ago
        I stand by my top comment, avoiding pushes Friday and waiting until Monday often leads to both code commit times on Monday and merge commit times on Monday. (Edit: and BTW I know this for a fact, because we monitored average commit times to make sure the policy was being adhered to.) If you look at the code from the article, you’ll see that the author did not filter out merge commits. The word merge doesn’t even appear in the article. The OPs data includes merge commits. You’re trying to draw a hard and idealized line that doesn’t exist in real companies. Squashes often happen right before push. Stashing for the weekend rather than committing is common. People unsafely leaving uncommitted changes in their workspace over the weekend is common. Most devs in my experience are not git experts, and they don’t always use git in best practices kinds of ways. That is made evident every time there’s a git thread on HN. I am talking about commit time, my push policy affects my commit times. You can’t count on commit times to demonstrate anything.
- efficax 7y ago
  We have emergency production rollback to the last working deploy. That's what you do when breaking changes are committed to master. Letting devs commit to master directly? Horrible idea.
  - dahart 7y ago
    That’s a great strategy that works in some scenarios. Preventing weekend breaks would depend on a daily deploy schedule? I do normally revert first and ask questions later when breaking changes appear, that’s similar to what you’re saying, I think... > Letting devs commit to master directly? Horrible idea. I’ve never been on a team that disallows commits to master. I can see the thinking, and maybe I should be doing that, but for whatever reason, the places I’ve been are less formal than that and they might be concerned about slowing down turnaround times during the day when people need to share things more quickly. FWIW, I am including git and also VCSs other than git. It’s harder to wall off the master branch in Perforce as a policy decision. And maybe I just haven’t been on a large enough team to warrant having someone with full time merge duties...
    - nitely 7y ago
      > the places I’ve been are less formal than that and they might be concerned about slowing down turnaround times during the day I'd be more concerned about code being committed to master without code review.
- martinhath 7y ago
  I think the reason for confusion is that you seem to say that people doesn't even commit their work when they work, but only when they're pushing as well. dchest is (seemingly) asking why don't you commit when you're done, but delay the pushing (according to your policies)?
  - dahart 7y ago
    The confusion was my fault, but I think is mostly gone now. I initially described it as commits when I was thinking of pushes, partly because I’m lumping both git and Perforce experience together. I edited my comments to be more clear, and it seems to have helped. The question asked is valid, and we do commit often, we only avoid pushes to shared spaces at night, so some commits may have representative time stamps. As others have mentioned, squashing might compromise that, and commits made Friday but pushed Monday are, in my experience, more likely to be modified Monday right before pushing. For me, it’s pretty rare that the first commit time survives until push, I’m almost always squashing code, multiple times, before it’s ever pushed.
    - martinhath 7y ago
      Absolutely! In addition, if you've spent a full day on a single commit, it'll show in these stats as a single data point at the end of the day - the fact that you were working for the 8 hours leading up to the commit as well is lost.
    - atq2119 7y ago
      This isn't entirely correct. Git commits have two timestamps: the author timestamp and the commit timestamp. Git only shows the author timestamp by default, and that timestamp definitely survives `git commit --amend` and other operations like rebase with squash. I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream. Unfortunately, TFA doesn't discuss which timestamp is being looked at, though that leads me to suspect that it's looking at the author timestamp because that's the default.
      - 7y ago
- kayoone 7y ago
  a merge to master should only be done after a review, eg. PR is accepted by X reviewers which most likely happens only during working hours. Not sure I understand your policy, people randomly committing/pushing to master without review is not a good idea at any time.
- beatgammit 7y ago
  For history noise, just rebase before merging and you won't get a merge commit. It's really easy and preserves the use of branches. Our process is: - create a branch for every change - make commits relatively small, but complete; each commit shouldn't break the build our the tests - request peer review when the code is ready to merge - when reviewed, rebase onto team's development branch and merge
cowsandmilk 7y ago
It always surprises me that workplaces with automatic deployment don’t have deploy windows. Automatic deployment only occurs 10-3 in your region and you can deploy by overriding outside that time to get out emergency fixes.
- hinkley 7y ago
  Most CI systems support running builds automatically on an interval, and I think some support time ranges as well. In a way a lot of this CI/CD stuff was easier when you ran it on your CI system.
0xdeadbeefbabe 7y ago
The policy is to risk breaking stuff only when people are in the office. It's a good concept.
bpizzi 7y ago
I think that 'to avoid merging or committing to public branches' means 'to avoid pushing' here, specifically the 'to public branches' part. Because, obviously, it's pushing commits that's problematic, not committing per se (in git vocabulary).

Strange policy about commits — why just not push at night or during weekends? Why's everyone not working on branches?

by dchest 7y ago

Strange policy about commits — why just not push at night or during weekends? Why's everyone not working on branches?

> Strange policy about commits — why just not push at night or during weekends? Why's everyone not working on branches That is what I’m saying. The policy is avoid pushes to master. My policy does apply to branches too once there are more than a few people in the branch. Lots of people do work in branches, but everywhere I’ve worked, plenty of people skip branching when they’re making what they think are “small” changes. And some places I’ve been, the team has decided on a policy to skip branches & merges for single commit changes due to the history noise it causes. The policy is to avoid breaking changes being committed to master when people aren’t around to notice & fix it.

stinkbug9o 7y ago
You’re describing merges, not commits, or pushes to remotes. One can commit and push to branches all day. Merging them to master without a heads up is a bad idea, except where teams have implemented a process that can handle it
- inlined 7y ago
  Many of us do a “squash merge” (use git rebase to compress to meaningful points in a CR and again before merging to master or feature branches). This creates a clean history at the expense of not being able to stalk others work at high granularity or get as large a score on github’s tracker.
  - testvox 7y ago
    Git rebase interactive with fixup or squash will combine the commits into the first one. So the timestamp will still be somewhat reflective of when work is done (on average).
    - inlined 7y ago
      Though I wouldn’t be surprised if there is at least some biasing. E.g. first commits happening relatively soon after regularly scheduled scrum meetings. At least if they’re the type of developer who checkpoints after incremental changes.
    - mandelbrotwurst 7y ago
      Are you sure? It seems fairly likely to me that the average time of day that someone makes the initial commit on a new branch would be quite different from the average time of day that they make commits generally. Am I misunderstanding?
  - MaxBarraclough 7y ago
    I'm not convinced that a 'clean history' beats a richer more fine-grain history. There's a reason frequent small commits are generally thought to be the way to go.
    - hoten 7y ago
      except of my dozens or so commits to a feature branch, most of which are "update" or "fix test" or "oops forgot edge case". But for the one squash commit, it's "some-feature-tag: nice description of the changes (#relevant-pr)". and there's no way I'm going to write more than one nice commit message for a branch. You can still get the fine-grained commits if you keep your merges focused on one thing.
      - MaxBarraclough 7y ago
        > You can still get the fine-grained commits if you keep your merges focused on one thing. Right. This is what Git Flow does. Best of both worlds.
  - hinkley 7y ago
    Stalking other workers at high granularity is sometimes the only way I have to figure out what was going through their head (or indeed, my head 2 years ago) when they wrote this... very interesting logic. The biggest WTF programmer I work with squashes all of his commits. So every commit is 100-400 lines of Rube Goldbergian majesty.
- dahart 7y ago
  > You’re describing merges, not commits, or pushes to remotes. Both merges and commits can be pushed. I’m not exactly sure what distinction you’re trying to make. Also, btw, I’m using git terminology, but not everyone uses git. I’m including my experience on teams that use Perforce, for example. > One can commit and push to branches all day. Merging them to master without a heads up is a bad idea. Yeah, right, exactly. You agree with me. My policy is about putting anything new in the master branch during off hours, because breaking changes that evade the tests may not get fixed until work hours, and prevent other people from working at night or over the weekend.
  - kragen 7y ago
    The article is about the times of day Git commits were made, not the times of day they were pushed, nor the times of day people used other source-control systems like Perforce. You said, "I’d be very cautious about assuming that commit time has anything to do with work time," citing your own policy of not pushing at night as an example of how "commit time" may not have anything to do with work time. Now you're saying, "My policy is about putting anything new in the master branch during off hours," which is to say, it's about pushes, not commits. This means that your original top-level comment is completely irrelevant to the article you are commenting on, which is unfortunate, since it's the top-voted comment on the article. You should edit the top-level comment to reflect that fact, or, if that's not possible, add a second-level comment retracting it.
    - dahart 7y ago
      I stand by my top comment, avoiding pushes Friday and waiting until Monday often leads to both code commit times on Monday and merge commit times on Monday. (Edit: and BTW I know this for a fact, because we monitored average commit times to make sure the policy was being adhered to.) If you look at the code from the article, you’ll see that the author did not filter out merge commits. The word merge doesn’t even appear in the article. The OPs data includes merge commits. You’re trying to draw a hard and idealized line that doesn’t exist in real companies. Squashes often happen right before push. Stashing for the weekend rather than committing is common. People unsafely leaving uncommitted changes in their workspace over the weekend is common. Most devs in my experience are not git experts, and they don’t always use git in best practices kinds of ways. That is made evident every time there’s a git thread on HN. I am talking about commit time, my push policy affects my commit times. You can’t count on commit times to demonstrate anything.
efficax 7y ago
We have emergency production rollback to the last working deploy. That's what you do when breaking changes are committed to master. Letting devs commit to master directly? Horrible idea.
- dahart 7y ago
  That’s a great strategy that works in some scenarios. Preventing weekend breaks would depend on a daily deploy schedule? I do normally revert first and ask questions later when breaking changes appear, that’s similar to what you’re saying, I think... > Letting devs commit to master directly? Horrible idea. I’ve never been on a team that disallows commits to master. I can see the thinking, and maybe I should be doing that, but for whatever reason, the places I’ve been are less formal than that and they might be concerned about slowing down turnaround times during the day when people need to share things more quickly. FWIW, I am including git and also VCSs other than git. It’s harder to wall off the master branch in Perforce as a policy decision. And maybe I just haven’t been on a large enough team to warrant having someone with full time merge duties...
  - nitely 7y ago
    > the places I’ve been are less formal than that and they might be concerned about slowing down turnaround times during the day I'd be more concerned about code being committed to master without code review.
martinhath 7y ago
I think the reason for confusion is that you seem to say that people doesn't even commit their work when they work, but only when they're pushing as well. dchest is (seemingly) asking why don't you commit when you're done, but delay the pushing (according to your policies)?
- dahart 7y ago
  The confusion was my fault, but I think is mostly gone now. I initially described it as commits when I was thinking of pushes, partly because I’m lumping both git and Perforce experience together. I edited my comments to be more clear, and it seems to have helped. The question asked is valid, and we do commit often, we only avoid pushes to shared spaces at night, so some commits may have representative time stamps. As others have mentioned, squashing might compromise that, and commits made Friday but pushed Monday are, in my experience, more likely to be modified Monday right before pushing. For me, it’s pretty rare that the first commit time survives until push, I’m almost always squashing code, multiple times, before it’s ever pushed.
  - martinhath 7y ago
    Absolutely! In addition, if you've spent a full day on a single commit, it'll show in these stats as a single data point at the end of the day - the fact that you were working for the 8 hours leading up to the commit as well is lost.
  - atq2119 7y ago
    This isn't entirely correct. Git commits have two timestamps: the author timestamp and the commit timestamp. Git only shows the author timestamp by default, and that timestamp definitely survives `git commit --amend` and other operations like rebase with squash. I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream. Unfortunately, TFA doesn't discuss which timestamp is being looked at, though that leads me to suspect that it's looking at the author timestamp because that's the default.
    - 7y ago
kayoone 7y ago
a merge to master should only be done after a review, eg. PR is accepted by X reviewers which most likely happens only during working hours. Not sure I understand your policy, people randomly committing/pushing to master without review is not a good idea at any time.
beatgammit 7y ago
For history noise, just rebase before merging and you won't get a merge commit. It's really easy and preserves the use of branches. Our process is: - create a branch for every change - make commits relatively small, but complete; each commit shouldn't break the build our the tests - request peer review when the code is ready to merge - when reviewed, rebase onto team's development branch and merge

cowsandmilk 7y ago

It always surprises me that workplaces with automatic deployment don’t have deploy windows. Automatic deployment only occurs 10-3 in your region and you can deploy by overriding outside that time to get out emergency fixes.

hinkley 7y ago
Most CI systems support running builds automatically on an interval, and I think some support time ranges as well. In a way a lot of this CI/CD stuff was easier when you ran it on your CI system.

0xdeadbeefbabe 7y ago

The policy is to risk breaking stuff only when people are in the office. It's a good concept.

bpizzi 7y ago

I think that 'to avoid merging or committing to public branches' means 'to avoid pushing' here, specifically the 'to public branches' part. Because, obviously, it's pushing commits that's problematic, not committing per se (in git vocabulary).