Git branching strategies for a microservice-oriented application

Git branching strategies for a microservice-oriented application

    A microservice-oriented application is a suite of independently deployable, highly cohesive and decentralized services. This may be the result of a brownfield approach (migrating an existing monolithic application into a microservice-oriented application) or of a greenfield approach (developed from the beginning as a microservice-oriented application).

    The codebase of a microservice-oriented application can be stored in a mono-repo or in a multi-repo approach. Mono-repo refers to a version control strategy in which all applications within an organization are stored in a single repository. Multi-repo, on the other hand, involves using multiple repositories to store and manage applications.

    Pros of mono-repo:

• lowers barriers of entry for new team members
• centrally located code management
• painless application-wide refactoring
• more difficult to break adjacent functionality
• teams share development culture

    Cons of mono-repo:

• feature branches can get out of control
• slower development cycles
• requires download of the entire codebase
• unmodified libraries may be newly versioned
• forking is more difficult

    Pros of multi-repo:

• independent service/library versioning
• independent service/library releasing
• helps define access control across the organization
• allows teams to work autonomously

    Cons of multi-repo:

• dependency management can get difficult
• code duplication happens more often
• changes can span multiple repositories
• versioning and dependency management can become complex
• separation of concerns can fail
• end to end tests in CI are hard to get right

    A microservice-oriented application can be deployed in a continuous delivery or in a continuous deployment approach. This are the Git branching contenders to watch as the CD race heats up:

    - Git Flow Workflow

• https://nvie.com/posts/a-successful-git-branching-model/
• https://docs.gitlab.com/ee/topics/gitlab_flow.html#git-workflow
• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

    - GitLab Flow Workflow

• https://docs.gitlab.com/ee/topics/gitlab_flow.html#introduction-to-gitlab-flow

    - GitHub Flow Workflow

• https://docs.github.com/en/get-started/quickstart/github-flow
• https://docs.gitlab.com/ee/topics/gitlab_flow.html#github-flow-as-a-simpler-alternative

    - Git Feature Branch Workflow

• https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
• https://docs.gitlab.com/ee/topics/gitlab_flow.html#feature-branch-workflow

    - Git Forking Workflow

• https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
• https://docs.gitlab.com/ee/topics/gitlab_flow.html#forking-workflow

    For single environment deployment applications, the following git branching strategies are recommended: Git Feature Branch Workflow, GitHub Flow Workflow.

    As a side note, for open-source applications, the Git Forking Workflow is commonly used to allow external contributors to work without direct access to the repository.

    For multi-env deployment applications, the following git branching strategies are recommended: GitLab Flow Workflow, Git Flow Workflow. 

    The Git Flow Workflow is a very complex workflow. It should only be used in the development of a complex microservice-oriented application with multi-env deployment that is explicitly versioned or in need of supporting multiple versions at the same time.

    Some tips that apply to any of the above git branching strategies:

• use Git LFS for large files while using .gitignore and .gitattributes to protect your repository from large files
• in a good workflow, the feature, hotfix and bugfix branches are deleted once they are merged back into the source branch to avoid a mess of outdated and not finished branches

Enjoy (ง°ل͜°)ง