1

I created a Git repository on BitBucket for a project with 5 committers. All of us are new to Git and are using TortoiseGit. We just have the master branch and all we want is a simple "SVN-like" workflow: get other people's changes, make some changes yourself, let other people see your changes.

One particular committer seems to be having a lot of trouble with Git and he's overwritten other people's changes several times now. Undoing the damage is very difficult, because I don't know much about Git either. I can't watch him as he uses Git, so I don't know exactly what he does, but I'd like to tell him: here's what to do to ensure this doesn't happen. For SVN that would be: before committing, always update first, merge your changes and test that everything still works. What should I tell him for Git?

EM0
  • 5,369
  • 7
  • 51
  • 85
  • You need to find out how he's over-writing changes. One way to overwrite changes is to force push. Another way is when resolving conflicts, he either messes up the conflict resolution, or he only stages his own files for commit (see [Tortoise Git - lost commits after a pull resulted in conflicts](http://stackoverflow.com/q/23120311/456814) and [What is the right way to commit/push when there are conflicts in Git or TortoiseGit?](http://stackoverflow.com/a/23122431/456814). –  Apr 20 '14 at 18:47
  • Also, while Git will allow you to use an SVN style workflow, if everyone is using Git, you're really better off using a Git Flow or GitHub Flow workflow. Also, it sounds like you need someone on your team who knows Git well enough to be able to help you guys out of these sort of situations. I highly recommend reading the [**FREE** online Pro Git book](http://git-scm.com/book). –  Apr 20 '14 at 18:48
  • Oh yeah, other things that you shouldn't do with git that could cause problems--these all involve rewriting ***public/shared*** commits/history: amending commits, rebasing commits, cherry-picking commits, etc. –  Apr 20 '14 at 18:55
  • Pro Git recommended chapters: chapters 1-3, 6-6.5. Learn how to rebase. Git is just a tree of commits, with movable Post-It notes (branches, refs, tags) attached. –  Apr 20 '14 at 19:09
  • Thank you. I will try to find out what's happening (if it happens again), but it won't be easy. Yeah, it was probably a mistake (mine!) to use Git without someone on the team who knows it. I seriously overestimated its usability. – EM0 Apr 20 '14 at 19:59

2 Answers2

3

If you're going to use git, you should use the power git offers... branches!

On the assumption that you don't want to complicate the workflow any more than necessary though, simply tell your developer that before committing, always git pull --rebase. In a nutshell, this will: a) save off your local changes, b) pull remote changes (that is, changes others have committed and pushed), c) replay your local changes onto the new code base.

mah
  • 39,056
  • 9
  • 76
  • 93
  • Thank you, --rebase looks promising. Based on http://stackoverflow.com/a/4675513/1536933 it looks like this would get us close to SVN behaviour. – EM0 Apr 20 '14 at 20:10
0

Have everyone pull from a 'team' source repo and push their work to their own repos. Then have an integration manager pull from all individual repos, merge it all together, and push it on to the team repo. This will ensure no one overwrites anyone else's work.

Yawar
  • 11,272
  • 4
  • 48
  • 80
  • That's an idea, but it's probably a last resort. The integration manager (me) wouldn't want to spend all his time merging everyone's changes. – EM0 Apr 20 '14 at 20:12
  • @EM - ah, then you'll have to teach the developers good merge and push etiquette.... – Yawar Apr 20 '14 at 21:09