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. Parker
