How do you avoid that people forget to run 'git push'?

I agree that ideally you can fix this simply by trying to give plenty of reminders. A few miscellaneous thoughts:

Anything that reinforces the distributed version control idea will help make people think of this more naturally. For example, I favor a workflow that includes using local topic branches and amending/rebasing commits until they're exactly what I want. If you teach how to do this, it becomes obvious that these are things done in your own area. As developers become more aware that their repo is different from the central one, remembering to push will get much easier.
If you're on your master branch (or any other branch that tracks a branch on origin), git-status will give you reminders like "Your branch is ahead of 'origin/master' by 1 commit." You'll also see this when you check out master.
You could, if you really wanted, write a post-commit hook that simply notifies the user how far they've diverged from origin. There are a lot of ways to approach this, depending on your workflow - perhaps just duplicate that status message, perhaps find the oldest commit on the current branch that isn't in origin so you can let them know how long it's been... Note that including hooks with the repository isn't trivial: .git/hooks is not tracked, so you have to symlink either the directory or the hooks inside it into the repo. This can be automated by a setup script, though, so it's not too bad!

It's not quite exactly the same. With git, it is much easier to resolve the problem than with svn.

William Pursell 2009-10-16 15:34:16

@William - I'd probably solve either problem by swinging a clue-by-four at the relevant dev's head. Same level of effort either way... ;)

retracile 2009-10-16 16:56:09

I don't agree that it's the same. A 'commit' in Subversion is very different from a commit in git. With git, it makes perfect sense to commit broken/experimental/crazy stuff, so you do it very often. That's not the case with Subversion. So mentally, doing a commit is detached from 'publishing your work'.

Frerich Raabe 2009-10-23 09:59:30

@Frerich - A 'commit' in subversion is the same as a 'push' in git; and you were asking about how to deal with devs who don't push. So, you deal with it the same way as someone not committing in subversion. As for committing experimental changes, that's what dev branches are for, even in subversion.

retracile 2009-10-23 13:03:43

@retractile: A 'commit' in subversion is *technically* (more or less) equivalent to a 'push' in git. What I'm talking about is the perception of a commit in git. It's an easy operation, it can be undone, it can be rewritten, it's not visible for others per se. So you do this all the time in git, but you don't do so in Subversion. With git, it's easy to develop features with your peers and forget to publish your changes to the package building host.

Frerich Raabe 2009-10-26 13:00:45

"but you don't do so in Subversion", except that I do; all those things that you commit in git, I also commit in svn, on branches. Fundamentally, it's a social problem -- teach your devs to push their work to the server on a regular basis (not just "when it's ready"); get them comfortable with branches so they can do so without interfering with others. Whether they are using svn or git doesn't change the social problem; just the technical details. Until it is on the server, it does not exist.

retracile 2009-10-26 15:45:39

That is a really good idea. It's much safer also because the tech lead can review the codes before they're checked-in to the blessed repository.

jpartogi 2009-10-18 23:09:56

One problem with this is that it can tend to remove the ability to force updates to be fast-forwards. A changeset may be based on origin/master when the dev makes it, but when the integrator pulls it there may be several such changesets from other devs. The history then becomes less linear, and the integrator has to perform real merges. And of course, it takes away one of the chief benefits of allowing pushing - freeing up someone's valuable time to do real work instead of integration.

Jefromi 2009-10-19 12:35:32

This would probably work, but we're very short on manpower, so I'd rather spread the responsibilities over all the developers instead of concentrating it on one person. Especially since the 'project lead' often cannot tell which changes are ready to be pulled, and which aren't.

Frerich Raabe 2009-10-23 10:00:53

ansaurus

tags:

views:

answers:

How do you avoid that people forget to run 'git push'?

related questions