Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

> And here I have to disagree strongly.  In a workflow based on a shared
> repository, you do not want to merge.  You want to rebase.  First  
> thing
> you do when switching to another branch is fetch + rebase (that's  
> why I
> want an option to "pull --rebase" other branches).
>
> But _even if_ you merge instead of rebase, I fail to see how the  
> current
> situation is different from CVS (which many people maintain is  
> _easier_
> than gi), where first thing you do is to "cvs update".  Just for  
> git it is
> "git pull".
>
> But I think I have to drive my message home again: if what you desire
> becomes reality, you take away the clear distinction between local
> and remote branches.  In fact, those branches are neither local  
> (because
> the next pull will automatically update them with remote changes, but
> _only_ if they fast-forward) nor remote (because you plan to work  
> on them
> locally).

> But here is a proposal which should make you and your developers  
> happy,
> _and_ should be even easier to explain:
>
> Work with topic branches.  And when you're done, delete them.

> So the beginning of the day could look like this:
>
> 	git fetch
> 	git checkout -b todays-topic origin/master
>
> 	[hack hack hack]
> 	[test test test]
> 	[debug debug debug]
> 	[occasionally commit]
> 	[occasionally git rebase -i origin/master]
>
> and the end of the topic
>
> 	git branch -M master
> 	git push origin master
>
> If you should not be ready to push by the end of the day, no need to
> worry.  Just stay on that topic branch, and before pushing, do
>
> 	git fetch
> 	git rebase origin/master
>
> In _every_ case where I explained git, I found that people  
> appreciated the
> two-step procedures (like you will find in the examples I showed you
> above): one git command to work locally, and one to push/fetch to/from
> origin.