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
prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).