Some merging thoughts/questions.

[infectedrhythms]

So I installed Plastic... And I got my source into the main branch.

The first thing I did was labeled the source as being the production version at that point of time. So far so good...

Now...

I need start developing 2+ sets of features. Some take longer then others to develop, but in the end it all come back together. We control what features go out to production in what order.

So at this point I create 2 branches off main from the last production label.

At the same time I have some patches for production, thus I create a couple of branches for those too based of the last production label.

So now I have 2 feature branches and say 1 patch branch.

Patches happen the quickest...

I want to keep main as the stable production version.

1- Merge the patches back to main right away. <-- Should I label at this point too?

2- Merge the patches to the 2 feature branches.

3- Go through full dev cycle with feature branch 1: dev, testsing, QA, repeat until good.

4- Label each feature branch 1 as rel to production.

5- Production team confirm deployment to production. Merge feature branch 1 to main branch and label main as production version.

6- Merge feature branch 2 with feature branch 1.

7- Go through full dev cycle with feature branch 2: dev, testsing, QA, repeat until good.

8- Label each feature branch 1 as rel to production.

9- Production team confirm deployment to production. Merge feature branch 2 to main branch and label main as production version.

Does this seem right?

[psantosl]

Hi there!

The workflow you outline in and of itself is ok but I could probably suggest a couple things that would maybe make the process a little easier perhaps. My recommended workflow (starting from the very beginning):

1.) Check in your code and label it as your initial starting point

2.) Create a child integration branch /main/chld1 set the inheritance point to LAST

3.) For every feature, bug fix, task, etc create an individual branch (/main/task1, /main/task2,...)

These task branches use the Labels to fix their inheritance points.

4.) For integration testing merge the feature branches to the /main/chld1 integration branch, this would be like merging to a copy of the /main branch which allows you to do more realistic regression and integration testing before merging back to /main

A second option is to use selectors which allows you to download /main/task1 and /main/task2 into your workspace and you can even label the result so other devs can get your workspace setup.

5.) Periodically label your /main branch at points where you need it but by keeping your tasks segregated into individual branches it is not necessary to label those specific bug fixes or features since you can use the branch.

This approach is perhaps more scalable as it is likely you will have many feature task branches over time and you can re-use the chld1 integration branch and over and over. Since it follows the lineage of /main. You can also delete the chld1 (better to rename and retire it) and create a new integration branch as need dictates, which may be nice to simplify more complex and challenging tasks such as doing major features or massive overhauls (like refactoring), but of course there are also always the Selectors way of doing things which itself doesn