Git branching strategy

[MuhammedIrfan]

In order to bring balance between flexibility and the need to collaborate and share code in a consistent manner, we propose to introduce a branching strategy.

• Use feature branches for all new features and bug fixes [team]/feature/[description].
• Merge feature branches into the [team]/development branch using pull requests.
• After the pull request has been merged, delete the feature branch.
• Testing branch [team]/testing would be derived from [team]/development.
• Tests would be done in [team]/test/[scenario] which would be branched from [team]/testing and merged back to the same.
• Merge [team]/testing to the main branch upon completing active tests.

[CyrusVorwald]

I agree with the naming convention and feature branching. Not sure about adding team in front of the branch name, as multiple teams may work on the same branch and it implicates siloing. I think that the testing and development branches may add unnecessary steps and increase time it takes to get a feature to production.

Would like to hear everyone's thoughts around branching strategy and decide democratically tomorrow.

[CyrusVorwald]

To summarize

• HugoByte does not need to change their workflow. Revisit after CI is complete.
• Git issues are assigned a time estimate in Zenhub.
• Git issues that are being worked on have an associated branch.
• When a Git issue starts being worked on, the issue goes into the "In Progress" column in Zenhub.
• If the Git issue is describing a feature, the naming convention of the branch is "feature/[issue #]-[description]".
• If the Git issue is describing a bug fix, the naming convention of the branch is "fix/[issue #]-[description]".
• Merge feature branches into the main branch using pull requests with at least 1 reviewer assigned.
• When a Git issue is submitted for pull request, the issue goes into the "Review / QA" column in Zenhub.
• It is preferable that branches be merged directly to main, but because CI is not yet added, features can be merged to "development" branch using pull requests.
• After the pull request has been merged, delete the feature branch, and close the Git issue
• When the Git issue is closed, the issue goes into the "Completed" column in Zenhub.

[andrii-kl]

@MuhammedIrfan @CyrusVorwald-ICON I would like to suggest to start using a standard GitFlow Workflow strategy. It's really simplify PRs review process and workflow.

master | develop | feature branches

Some articles on this topic:

https://vitalflux.com/gitflow-workflow-best-practices-quiz-questions/

https://medium.com/itrevolution/five-minute-devops-gitflow-best-practices-a6cd1265de24

[CyrusVorwald]

See #128 (comment)

[CyrusVorwald]

@andrii-kl I also found this explanation of what I was describing that I think overviews things best https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow