>I think we made a serious mistake by pushing the nvie branching model 
>(http://nvie.com/posts/a-successful-git-branching-model/) 

First, we aren't using that branching model. Not even close. That model defines 
a viable workflow that we use successfully on many projects open and internal 
(5 to 500 people). What we have is a single git repo, and people who are new to 
git fighting over how to use the develop branch. I disagree with a lot of what 
you have said in the rest of your message honestly. However, I am not actively 
committing code and others are. I do think you can keep things simple. To be 
clear, there is a danger in what you mentioned, and it was what Fred was trying 
to address. So, let me mainly discuss that.

>>
1. Edit your files. No Git command required.
2. Merge in other people's work with 'git pull'.
3. If there a merge conflicts, fix them by editing. No Git command required.
4. See what files you've changed or added with 'git status'.
5. See what you've changed in a file with 'git diff <file>'.
6. Commit (to your local repo) what you've done with 'git commit -a'.
7. Share what you've done (in the public repo) with 'git push'.
>>

Okay, at its heart, the danger Fred was worried about is that, using a merge 
workflow, the person who pulls the changes needs to make sure they commit all 
changes... even files they didn't touch, because they 'inherit' the merge. So, 
the thing that just needs to be made exceptionally clear on step 6 is that... 
even if they don't believe they touched the file.... they need to make sure it 
gets committed.

For those new to git, if you are using this workflow, take a look at SmartGit. 
Its free to work on open source projects AND, mostly importantly, it would work 
find with the workflow you are proposing. It also handles merges well, which is 
going to be needed in this model.

That my 2 cents. You can take this any way you want, I simply wanted to 
elucidate the one major danger that Fred was trying to fix. If users aren't 
careful in step 6, they end up committing a merge without someone elses change.

Mike


Reply via email to