On Fri, Jun 10, 2011 at 9:32 AM, Cornelius Schumacher <[email protected]> wrote: > On Thursday 09 June 2011 John Layt wrote: >> >> Besides the inconsistency that >> Torgey also found, the one part of the command flow I'm wondering about is >> whether for the simple workflow we tell them to push or merge their >> commits into master? > > If it's a local branch, rebase the branch, merge it to master, and then push > it. This will give linear history. It should be equivalent to working in > master, rebasing on pull and just pushing, but it's cleaner and safer to do > the development in a branch. > > If it's a remote branch, just merge it and push it. > > In general it's a good idea to do a "git pull --rebase", when pulling as this > doesn't create merge commits with local changes, which can clutter up the > history.
I guess I need not say that you need to be *very* careful when doing this? You should do this prior to performing the merge, but never after. Just do a standard pull after that - otherwise it will rebase the entire merge. > > -- > Cornelius Schumacher <[email protected]> > Regards, Ben Cooksley KDE Sysadmin
