On Wednesday 02 February 2011, John Layt wrote: > On Wednesday 02 February 2011 13:43:04 Parker Coates wrote: > > My preferred workflow is to put all local commits intended for master > > in a single, local, long-lived "workmaster" branch instead of putting > > them in master directly. Since the changes are local, you can just > > keep rebasing it onto master every time master is updated. > > > > Then if you want to push a single commit from the work branch: > > * pull master > > * you interactively rebase the workmaster branch onto master to > > put the desired commit first > > * merge the SHA you want to commit into master > > * push master > > > > I find that by keeping my commits out of master itself allows me to > > update without worries, to commit high priority fixes without messing > > up my local work, and to commit early and often locally while still > > having the option to clean things up later with some rebasing. > > > > Personally, I found this ability to keep my local commit queue out of > > the way was the biggest advantage of switching to Git. > > > > Parker > > Personally, I think you should NEVER have commits in master, you should > only ever work in and push from branches, they're so cheap to do. That way > your master is always a clean pure copy of the main repo to branch off.
I don't really care how it will be, but I really think we should agree on one common recommended and documented workflow to use. Alex
