Git Workflow in Software Development Life Cycle

What is Gitflow and how it Works?

The Gitflow Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects. Gitflow is ideally suited for projects that have a scheduled release cycle.

Some key takeaways to know about Gitflow are:

1. The workflow is great for a release-based software workflow.
2. Gitflow offers a dedicated channel for hotfixes to production.

The overall flow of Gitflow is:

1. A develop branch is created from master.
2. A release branch is created from develop.
3. Feature branches are created from develop.
4. When a feature is complete it is merged into the develop branch.
5. When the release branch is done it is merged into develop and master.
6. If an issue in master is detected a hotfix branch is created from master.
7. Once the hotfix is complete it is merged to both develop and master

Gitflow with pull request:

Pull requests let you tell others about changes you’ve pushed to a branch in a repository. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

How the pull request works with Gitflow?

Adding pull requests to the Gitflow Workflow gives developers a convenient place to talk about a release branch or a maintenance branch while they’re working on it.

A developer simply files a pull request when a feature, release, or hotfix branch needs to be reviewed, and the rest of the team will be notified.

Features are generally merged into the develop branch, while release and hotfix branches are merged into both develop and master. Pull requests can be used to formally manage all of these merges.

The overall flow of Gitflow with Pull Request is:

1. A developer creates the feature, release or hotfix in a dedicated branch in their local repo.
2. The developer pushes the branch to a public remote repository.
3. The developer files a pull request via remote server.
4. The rest of the team reviews the code, discusses it, and alters it.
5. The project maintainer merges the feature, release or hotfix into the official repository and closes the pull request.