On Mon, Mar 30, 2009 at 06:22:26AM +0200, Nicolas Sebrecht wrote:
>
>
> On Mon, Mar 30, 2009 at 11:03:28AM +0800, Aaron Davies wrote:
> >
> > hi, i'm new to git, and have a couple questions which are probably
> > very stupid and/or indicate that i've been doing it wrong.
> >
> > first, a couple words about my setup/workflow: i'm currently sole
> > developer on a project which may at some point get some other coders.
> > the environment is three linux boxes, one for development and two for
> > production, and three accounts, mine, dev, and prod. all homedirs are
> > hosted on the network and are accessible from all three boxen.
> >
> > i have a "central" (i.e. bare) repository stored in dev's homedir, and
> > regular copies in all three homedirs. the language involved is
> > interpreted, so the code tree is the deployment.
> >
> > my main workflow is to hack on a branch in my homedir, then merge and
> > push when i have a feature ready. then i go to the dev account and
> > pull, which constitutes dev deployment. once it's thoroughly tested, i
> > do the same in the prod account.
>
> Looks sane.
>
> That said, you could also work on branches (all in "homedir") for the
> 'working on feature' -> testing (dev) -> ready (prod)
> workflow.
>
> > now, the questions: an exception to this workflow occurred a couple
> > months ago, when i made some urgent bugfixes that needed to move to
> > prod before other stuff that was currently being tested in dev. this
> > was done via cherry-picking some specific commits into prod. now, in
> > prod, when i do "git status", it says "# Your branch is ahead of
> > 'origin/master' by 8 commits." is there an easy way to get rid of
> > this?
>
> What I would do is working on "TOPIC" branches. By this way, the bare,
> dev and prod repositories would not "know" of all the commits from mine
> but only the urgent fixes.
>
> in "mine":
> - step 1
> $ git checkout -b bugfixes master
>
> - step 2
> $ git cherry-pick blabla
> (and/or <hack, hack, hack>)
>
> - step 3
> $ git checkout master
> $ git merge bugfixes
>
> - step 4
> $ git push origin master:master (to the bare repo)
>
> - step 5
> $ git branch -d bugfixes
> $ git checkout myworking
> $ git rebase myworking master
My bad:
$ git rebase master
> At step 1, we create the new bugfixes branch from master:
> (bugfixes)
> /
> o-o-o (master)
> \
> a-b-c-d (myworking)
>
> At step 2, we fix the bugs (cherry-picking and hack):
> a-c-y-z (bugfixes)
> /
> o-o-o (master)
> \
> a-b-c-d (myworking)
>
> At step 3, we merge the urgent fixes into master:
> a-c-y-z (bugfixes)
> /
> o-o-o-a-c-y-z (master)
> \
> a-b-c-d (myworking)
>
> At step 4, we push the urgent work as usual pushes.
> At step 5, we come back to the usual work:
>
> o-o-o-a-c-y-z (master)
> \
> b'-d' (myworking)
Then, you update dev and prod as usual from bare.
--
Nicolas Sebrecht
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
