Re: newb questions: post-cherry-pick status cleanup, shared local repository permissions

From: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Date: Mar 30, 2009, 04:22 UTC
Message-ID: <20090330042226.GA12907@vidovic>
In-Reply-To: <c4e763ac0903292003j22934e7ax9f9ae986bdcd6abb@mail.gmail.com>

On Mon, Mar 30, 2009 at 11:03:28AM +0800, Aaron Davies wrote:

Show 18 quoted lines

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

Show 7 quoted lines

> 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

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)

>From here, you update dev and prod as usual.

-- 
Nicolas Sebrecht