All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: robert mena <robert.mena@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Branching strategies
Date: Thu, 15 Sep 2011 04:07:03 -0700 (PDT)	[thread overview]
Message-ID: <m3ty8errkd.fsf@localhost.localdomain> (raw)
In-Reply-To: <CAAZ43xaFzJWzPsqhP0QDRTP0Ea-dMpCpr1vDiujFFn94j+SRCQ@mail.gmail.com>

robert mena <robert.mena@gmail.com> writes:

> I have a project where I have to do a continuous integration, adding
> features/making changes on a daily basis.  Some changes are one liners
> with no functionality just, for example, textual changes or a new
> button.   Some are actual features or bug fixes.
> 
> So today my developers do their business and publish the changes in a
> beta site where the customer or the qa takes a look.  The problem is
> a standard one.  Sometimes features stay already developed (waiting
> for review) for a long time and other changes/features get approved
> first.
> 
> Since some of those can touch the same files how can I make this a
> little bit better (manageable)?
> 
> I am considering doing feature branches.   The customer requests to
> add feature A I open a bug tracking issue and create a branch 1276
> corresponding to the bug id.
> 
> In my simply view I'd have a master/live branch and every time I need
> to create a new branch I do it from here.  When the developer is happy
> he merges his branch with a beta branch where the Q&A/customer review
> is done.
> 
> When this review gets an OK he merges his feature branch with the live
> one, redo the tests and publish.
> 
> I'd really appreciate feedback for this specially for the weak points
> and known problems of my approach with alternatives :)

The "Version Control by Example" by Eric Sink, http://www.ericsink.com/vcbe/
contains chapter about workflows, including feature branch workflow.

Junio Hamano blog (the old version) included a few articles about
using feature-branch workflow too.

HTH.
-- 
Jakub Narębski

      parent reply	other threads:[~2011-09-15 11:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09 23:01 Branching strategies robert mena
2011-09-10  1:18 ` Andrew Ardill
2011-09-19 18:51   ` gitlist
2011-09-20  0:12     ` Andrew Ardill
2011-09-15 11:07 ` Jakub Narebski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3ty8errkd.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=robert.mena@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.