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. If I needed to extract a single commit out of a branch to push, rather than merging it to master I'd create a new branch from master and cherry-pick the commit to that, build and test it knowing it's clean, then push from there. Then pull master and rebase the original branch on master again. John.