On Jun 16, 2008, at 4:12 PM, [EMAIL PROTECTED] wrote: > > Apologies for bringing up this old thread but being rather new to git > and this community, I don't want to step on any toes - but does anyone > have a solid example of their typical git workflow? > > My typical workflow and setup ( for facter ) at the moment is: > > Setup - > - Clone lak's git repo of facter > - Branch to my own dev branch > > Reoccuring: > - Checkout my branch. Branch from my branch into appropriate topic > branch (facter_ver/ticket_####) and check that out. > - Work on ticket, test, commit to topic branch > - Merge ticket back into my dev branch > - Rebase my dev branch > - Push my dev branch up to github > > Is this preferrable? Or should I just skip the part of having my own > dev branch, branch off the master for each topic branch and then push > each topic branch up to my github repo for the maintainer's to pull > from?
I recommend directly branching off of the main branch each time, either master or 0.24.x depending on what you're working on. Then you're only pushing individual topic branches, so we can assess each commit set separately. It might be that some of your commits need further work while others are directly mergeable; in that case, we need to be able to pick and choose, and if you publish them all in one piece, all we can do is cherry-pick. That's basically what my workflow looks like. If I know what I'm doing when I start (e.g., fixing bug #1232), I do this: $ git checkout 0.24.x $ git checkout -b tickets/0.24.x/1232 ... do work ... ... run tests ... $ git commit -a $ git push luke tickets/0.24.x/1232 $ git-format-patch -C -M -s -n 0.24.x..HEAD $ git send-email --no-chain-reply-to --no-signed-off-by-cc --suppress- from --no-thread --to [email protected] 00*.patch $ rm 00* If I don't know what I'm doing yet, then I skip the separate branch until I do. I'll just directly edit stuff until I have enough to make a ticket or know whether I'm making a new feature or whatever; then I branch et al. One great thing about git is that as you switch branches (e.g., from 0.24.x to your new topic branch) it will apply your uncommitted changes to the next branch, so you can safely edit in the main branch, as long as you don't commit there. Another useful trick is 'git reset' -- I have recently been using it to make temporary commits (essentially long-lived versions of 'git stash'), with something like 'REVERT THIS' in the commit msg. Then, when I go back to work on that banch, I just do 'git reset ^HEAD' (or, if necessary, reset to the specific previous commit). This makes it easy to store state in a branch and get back to it later. A similar technique makes it easy to commit, then branch, and then rewind the csource branch. I'm glad to elaborate if you're interested. -- The remarkable thing about Shakespeare is that he really is very good, in spite of all the people who say he is very good. -- Robert Graves --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
