Skip to content

Instantly share code, notes, and snippets.

@kaiomagalhaes

kaiomagalhaes/01-edited.md

Last active April 9, 2019 17:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kaiomagalhaes/d0200d8ad701bf3815325ab3392669fd to your computer and use it in GitHub Desktop.
Save kaiomagalhaes/d0200d8ad701bf3815325ab3392669fd to your computer and use it in GitHub Desktop.
Download ZIP
Raw
01-edited.md

Git flow proposal 1

Goal

Follow the community best practices and deliver the features fast.

General git flow

On the ACST repository we will have:

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

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

c. 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 create a branch from develop name feature/feature-name
  3. The developer pushes all his commits to feature/feature-name
  4. The developer creates a pull request from feature/feature-name to develop
  5. The Codelitt and ACST developers will review and approve it
  6. The branch feature/feature-name will be merged to develop once it has two or more approvals for either the Codelitt or the ACST team.

Pros:

I. The development team will deliver the solutions faster

II. The amount of code conflicts between branches will be small

III. ACST will be able to test the changes faster

Cons:

I. Although the ACST developer will be notified every time and we will request his approval, it won't be mandatory to merge the branch into develop/master branches.

Branching flow

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.

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:

Usually spotted by codelitt's PM or a member of the dev team. These bugs will be fixed and merged into development branch.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment