[Vtigercrm-developers] Vtiger 7.1 RC Released

[Alan Lord]

+1 Nilay,

This is pretty similar to what we do.

Branching is "cheap" and easy with Git so I agree with this approach.

Where a bug is rather complex or needs focussed attention/testing, do it 
on a branch (we use the issue number as the prefix to the branch name, e.g.

1234_BugWithFeatureA

For _new_ feature development, again create new branches (with sensible 
names for the features).

You work on that (and yes you can keep it synchronised with master if 
you pull in the right direction).

Then when the bug looks good, it is merged into to the "staging" or main 
development branch for testing.

If the bug is small or fairly trivial, a pull request can be made 
directly against the staging branch.

Once that staging branch is at a point where the devs consider it is 
ready for a release, tag it (maybe as an RC), test it (and *delete* the 
already merged-in bug and feature branches). If it passes all the tests 
[<cough>unit tests</cough>], merge into master and tag the full release.


HTH

Al


On 31/01/18 06:18, nilay khatri wrote:
> We have been working on git since a long and until now following setup 
> has worked:
> 
> 1. For major each issue create a separate branch
> 2. Have a staging/Dev branch (for each version release). As an issue is 
> fixed, send a merge request to the Staging Branch
> 3. Perform all testing on the staging branch
> 4. Once the staging has passed tests, merge it with the master and tag a 
> new release version
> 
> 
> In such case, when some one wants to commit to master, they can send a 
> merge request to the Staging Branch
> 
> regards,
> Nilay Khatri
> Founder, Automate SMB
> /Vtiger CRM implementation/Customization | Sales and Marketing Automation /