The industry standard for branching and merging it to keep everyone in sync with the process so that we always know the status of the project.
- Branching: when creating new features
- create new branch when the feature is different than existing branches, or will cause lof of file conflicts.
- use existing branch if its an small addition/bug fix to the existing branch
- Code review: once development is done, the codes should be reviewed by someone with more experience with the codebase. Code quality is checked here to make sure we dont push in patch codes that cause more problems later.
- example remove dev comments, and print lines statements.
- Approval: this step should be done with the business owner or project manager that the feature is accepted as expected. this help use log the changes and filter bad/misunderstood features.
- Merging: once all the integration over tests passes, we have high confidence that the changes wont break the master. we push this to a dev or staging branch. We then run more tests and make sure the UI tests also works as expected
- jenkins would be great to automate the merging process. creating the docker image with the new updates. run the app and the tests as part of the pipeline. once everything passes, then we merge it into stage.
- Release: we would sync up the stage into the master branch.
- sometimes running ab testing to testout the new feature and see how the site performs in live before rolling out to the whole public.
My thoughts: Sometime developers bypass the code review process and push codes into the stage. those changes are usually not tested or checked at all. Other times quick fixes directly into master might work for while, but cause major conflicts for the existing branch or not considered usages in other environments. Those are bad habits that often cause the server to crash or not perform as expected.