On 2 February 2011 14:23, Parker Coates <parker.coa...@kdemail.net> wrote: > On Wed, Feb 2, 2011 at 09:05, 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. >> >> 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. > > Hmm. You're probably right. The majority of my Git experience has been > with git-svn where it's pretty much mandatory to commit via master. In > a pure Git environment, I guess it should be possible to keep master > 100% clean.
It seems that I go against the grain, and always develop in master. You already have "origin/master" as a pristine version of upstream master, and you don't have to worry about it getting out of sync. E.g: git log #find SHA1 of commit I want to push upstream git checkout origin/master #we are now on an "unnamed" branch git cherry-pick SHA # still on an 'unnamed branch' #compile, test, fix, etc. git push origin HEAD:master git checkout master git pull --rebase #rebase on top of remote, which now has our change John
