The way I work which I think works well is: 1) While developing, do whatever you feel like in your branch. So lots of merge commits are fine since as pointed out, rebasing can make multi party collaboration a little difficult at times.
2) When a point is reached where you want to push some work upstream, create a new temporary branch. Rebase the changes you want to push onto the current upstream master and just generally get it all into a nice state for pushing. So at this point I'll do something like 'git rebase -i HEAD~20' and squash some commits into 1 commit, change commit messages .... 3) Push the changes in your temporary branch upstream, can delete the temporary branch now. 4) Pull in the latest upstream master that contains your changes. Rebase your development branch to be on top of master. You have to be careful doing this though since all the rebasing does mean that commit id's change and if you make a mistake you can end up with some weird branches where a commit appears twice in the log. Step 4 when collaborating will also require you do a forced update to the shared repo and send emails out letting every know they need to be prepared for this. It shouldn't be hard at all for them to pull in the changed shared repo branch into a new branch, and port their uncommitted patches to the new branch. (e.g cherry pick or many other ways). I don't know if this is the best approach, I feel I know git well but haven't used it much in a collaborative setting. However it works well for me. The danger as always with this is how rebase changes history but as long as you do everything in new throw away branches and check carefully you should be fine. ~ David On 6 May 2011 11:06, Isaac Dupree <m...@isaac.cedarswampstudios.org> wrote: > On 05/06/11 05:15, Simon Peyton-Jones wrote: >> >> So I think merging the master onto the branch must be done regularly not >> as a big bang at the end. >> >> If someone would like to write a duffers guide describing how to do that, >> I'm happy to follow it. But the only way I understand is to merge master >> onto the branch regularly, and finally merge the branch onto the master. I >> don't see the disadvantage of this approach. Yet. > > I suppose one could (frequently) make a new throwaway branch that merges the > current branch work and HEAD in order to validate it. > > I remember hearing that git-rerere is supposed to facilitate that. Like > when conflicts between branch and HEAD need to be resolved in a certain way, > it can remember that for you..(haven't used it myself). > > That sounds slightly like madness to me..Nevertheless is it a suggested > workflow? (Does it work well?) Is Googling the way to find answers? > > -Isaac > > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc@haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc > _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
