Version control is certainly part of "coding well with others", but there's "dumping stuff in chronologically" and the kind of discipline needed to collaborate well. Sometimes the discipline isn't as hard as it looks at first...
I recently joined a tiny fast-moving team that was already using git,
and we're trying to be "as disciplined as we can afford to be" - the
primary external motivator is to keep a stable enough master that
we can safely run demos off of it, but at the same time have those
demos include recent progress. Large chunks of work get done on
branches and reviewed; small things, especially things that impact one
file and are easily tested on their own, can go straight in with less
fanfare.
Problem is that you start one of these small changes, committing as
you go, when you suddently realize it's become a large one and
"probably should have been on a branch all along". Well, if you
haven't git pushed yet (because you're working on master and hoping
you can just push a working change - it's not just luck that this ends
up being true so you can use this trick) you can "retcon" that with
two commands:
# You're already in the checkout, on master. # Create a local branch of the work... $ git checkout -b best-intentions # now master and best-intentions both have your changes. # "unzip" master back to the push point: $ git branch -f master $(git rev-parse origin/master) # now master has been "reconnected" at the point where you last # pushed; the next pull will update that smoothly... # # Bonus points: track the newly created branch properly $ git push --set-upstream origin best-intentions
That's it, now you can get the new branch reviewed properly.
Most of the branches I use at work are quasi-independent feature
branches, but I'm dipping into various ones at various times to help
out, review, or test... and since our product takes a couple of
minutes to build from scratch, the "one checkout that switches
branches" model doesn't make any sense at all (really it's never
made sense on anything large that I've worked on; for the cases where
it did work, using git stash instead has always worked better) so
I have a bunch of entire source and build trees.
Usually when I start the day I want to get all of them "caught up" to
everyone else's work; taking advantage of the "git extension script"
mechanism, I have a trivial git-morning script that finds all of my
checkouts and just does a git pull in each of them. I have not been
brave enough to have it do a git merge origin/master too, but I'll
probably try the experiment soon just to see if it saves more time
than it wastes from having to do all the cleanup first thing.