02-edited.md

Git flow proposal 2

Goal

Deliver the features fast and keep the ACST team on of the master branch

General git flow

On the Codelitt repository we will have:

a. The develop: This branch will be used as the default one for development.

On the ACST repository we will have:

a. The master: This branch will be used as the base branch and will be the one deployed to the QA environment

b. The tags: The tags will be stable releases that will be deployed in production

Develpment flow

1. The developer starts a feature
2. The developer creates a branch from develop named feature/feature-name on the Codelitt repository.
3. The developer pushes all his commits to feature/feature-name
4. The developer creates a pull request from feature/feature-name to develop still on the Codelitt repository.
5. The Codelitt developers will review and approve it
6. The branch feature/feature-name will be merged to develop once it has two or more approvals from the Codelitt team.
7. The developer will create a new branch named feature/feature-name-acst from develop and create a pull request from feature/feature-name-acst(Codelitt repo) to the master(ACST branch)

Pros:

I. The ACST team will stay on top of all the changes done on master

Cons:

I. The amount of code conflicts between branches could be big

II. The frequency of updates on QA will be smaller

III. The ACST team will need to provide an exclusive resource to review the pull requests

Branching flow

ACST repository

Master

This branch contains the latest stable version of the webcms. When updated this branch triggers a new release to the QA environment, therefore creates a version that can be tested by the ACST team.

Tags

After ACST team has QAed the latest release to QA and approved it, a new tag is created following the semantic versioning https://semver.org/. This new tag will be deployed to PROD.

Codelitt repository

Development

This branch has the latest changes from the development team. Therefore it's an unstable branch. It'll be deployed to the DEV environment, where codelitt's PM can run a QA to make sure the features are okay. The development team will work on feature branches that will be merged into development when done.

General bugfix flow

Bugs in DEV environment:

This environment won't exist, therefore the Codelitt's project manager won't be capable of reviewing the tasks on the development cycle

Bugs in QA environment:

Usually found by ACST team. To fix this bug, the dev will need to branch off of master and open a PR to be first merged into master. After it's merged to master, the dev will create a new PR to merge the bugfix into development.

Bugs in PROD environment:

Could be reported by a user or by a bug alert. To fix this bug the dev will need to branch off of the latest released tag, and after the fix is done, it's going to be deployed to an environment that mimics PROD so that the bugfix can be QAed. If the bugfix is approved, a new tag will be created for the bugfix, and the dev will create a new PR to merge the bugfix into development.

Branch names

Branches names, should follow the rules described below:

feature/branch-name - for new features

fix/branch-name - for bug fixes in DEV

hotfix/branch-name - for bug fixes in the latest version deployed to QA or PROD

update/branch-name - for updates that are not bug fixes or features

These branches, except for the hotfix, will be merged into development once they're ready. The hotfix branch will be merged into master, and a new fix branch must be created to be merged into development.