Branching strategies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

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 :)

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]