I like pictures.
http://osteele.com/archives/2008/05/my-git-workflow
http://osteele.com/archives/2008/05/commit-policies
I've only been using git for about 6 months and really only for about 3.
I thought these two articles gave me the reference point I needed to
map out more of how the git thing works in my mind.
Might be useful for you.
On Jun 16, 2008, at 4:15 PM, Luke Kanies wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
