3 ms·

> but the act of committing their changes (or pushing it to a branch, if you are PR-driven) I'm not sure if I understand you entirely correct, but it seems the

by berkes 5y ago

> but the act of committing their changes (or pushing it to a branch, if you are PR-driven) I'm not sure if I understand you entirely correct, but it seems the "you have to commit" is a large part of the problem. You don't. Your harddrive is not going to crash between tonight and tomorrow. And if it may, and this is crucial, git is not a backup system, so get a proper backup system in place. Commit when you have a coherent piece of work done. Or maybe commit a "WIP: working on foo, halted for emergency hotfix X" if stashing is out of the question. Part of my "INK" workflow is not committing to RCS. Leave the dirty state as another mental nudge what you were working on; and add your current memory-state as annotations in the code behind an INK. I've mentored a junior and he was the opposite, never committed untill he was finished, sometimes work of multiple weeks, then he commited it with "finished the FooBar". We agreed he would try to commit at least daily. So then he made one commit a day. "17:00 going home. commit" in the logs. Every day. Needless to say, we did not keep him for long.

hinkley 5y ago
> Commit when you have a coherent piece of work done. No, that's the problem. Commit when you are available to deal with the consequences of commit. Having a coherent piece of work reduces, but does not eliminate the chance for problems. If you leave before the code builds, you've created problems for someone else to fix. If you haven't budgeted time for the rollback to go wrong on the first try, you're creating problems for other people. This is why reliability and responsiveness of CI/CD systems matter much more than most people allow. On a good project, pushing things after 4 is probably a bad idea. On less well run systems, anything after 3 might be risky. On a bad one, 2:30 might be pushing things. So depending on meetings and lunch time there may be very small intervals where you can push things, and when the clock is ticking we begin to rationalize, which just makes the likelihood of failure increase.
- berkes 5y ago
  > If you leave before the code builds, you've created problems for someone else to fix. I'm curious to your workflow now. How can it be someone else's problem if you do not commit (and/or don't push) your work? Is everyone working only on master/main/develop branch? Do you work in a shared drive? Is your entire team working off a dropbox or network drive (I've seen this, I needed eyebleech)?
- account42 5y ago
  A commit does not have any consequences. A push may.

by berkes 5y ago

hinkley 5y ago

> Commit when you have a coherent piece of work done. No, that's the problem. Commit when you are available to deal with the consequences of commit. Having a coherent piece of work reduces, but does not eliminate the chance for problems. If you leave before the code builds, you've created problems for someone else to fix. If you haven't budgeted time for the rollback to go wrong on the first try, you're creating problems for other people. This is why reliability and responsiveness of CI/CD systems matter much more than most people allow. On a good project, pushing things after 4 is probably a bad idea. On less well run systems, anything after 3 might be risky. On a bad one, 2:30 might be pushing things. So depending on meetings and lunch time there may be very small intervals where you can push things, and when the clock is ticking we begin to rationalize, which just makes the likelihood of failure increase.

berkes 5y ago
> If you leave before the code builds, you've created problems for someone else to fix. I'm curious to your workflow now. How can it be someone else's problem if you do not commit (and/or don't push) your work? Is everyone working only on master/main/develop branch? Do you work in a shared drive? Is your entire team working off a dropbox or network drive (I've seen this, I needed eyebleech)?
account42 5y ago
A commit does not have any consequences. A push may.