The workflow is simple terms is “Change Management” what I mean by that Is workflow basically provides a way for a large number of people to contribute to a single work parallelly but effectively.

There is no universal solution which matches every team, but today we are looking into most commonly used git workflows.

1. Centralized Workflow

Simplest way of using git is the Centralized workflow, this method is ideal for people who are moving from SVN to Git as a starting point because the process is little similar to SVN.
In a centralized workflow, team members will be committing to the same branch ( master ) and conflicts resolving will happen directly in the master branch.

2. Feature Branch Workflow

This method is the one which is very popular and easy to adopt, Attlassian (the company behind the Bitbucket) uses this same method.
In this Method,
the master branch will be always production-ready, none of the members should be directly committing to the master branch.
We create a feature branch for each and every feature and bug fix
when we ready to merge back to master then we first merge master back to the feature branch and resolve conflicts if exists then run the tests against it and finally if all good merge back to master branch.

3. Feature Branch Workflow 2

This version of feature branch workflow we use dedicated branch for integrations so all of your feature branches should merge back to the integration branch and then merge back to the master whenever we are ready for a release. If the team is not ready for a release they will keep on merging back to the integration branch but they should not merge back to the master.

4. Gitflow Workflow

Gitflow Workflow is actually an extended version of Feature branch workflow, in this workflow, we are introducing hotfix branch and release branch and that will provide a strict way of handling everyday situations like “quick bug fix and release directly”, “working on a release”

In Gitflow we have 2 permanent branches called master and develop, the master is kept only for the releases which mean whenever you merge something to master branch it directly for the production so you need to always create tags whenever merging back to the master.

Hotfixes which need to go directly to the production then you checkout a specific tag into a hotfix branch and then fix it and merge back to master as well as the develop branch
if there is a feature then similar to feature branch workflow you create a feature branch and then merge back to develop when it is done.
If you are working on a release then you create a release branch. Purpose of a release branch is then you can focus more on that particular release and fix bugs etc, once you are ready to release then you will be merging back the release branch to master as well as the develop branch

5. Forking Workflow

This is the workflow used to manage open source projects in GitHub, instead of having single remote repository, in this method each and every developer will have a remote repository which is a clone of the original one these developers now can continue to develop the project whenever they feel that they have done something which may good to have in the original project they will send a pull request to the original repo, at this point someone will review the pull request and merge back or rejected.

Would love to learn about git-cherry-pic ?