flow - the act of flowing or streaming; continuous progression
A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner. Git workflows encourage users to leverage Git effectively and consistently.
the Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes to the project.
The default development branch is called master and all changes are committed into this branch.
This workflow doesn’t require any other branches besides master.
The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated feature branch instead of the master branch.
master represents the official project historyfeature branch.Pull request to Resolve feedbackThe Gitflow Workflow defines a strict branching model designed around the project release.
In addition to feature branches, it uses individual branches for preparing, maintaining, and recording releases.
Instead of a single master branch, this workflow uses two branches to record the history of the project.
master branch stores the official release history
develop branch serves as an integration branch for features.
Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration.
But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master.
release branches are based on the develop branch.
Once develop has acquired enough features for a release (or a predetermined release date is approaching), developer can fork a release branch off of develop.
Once the release is ready to ship, it will get merged it into masterand develop, then the release branch will be deleted.
Maintenance or hotfix branches are based on master instead of develop. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and master should be tagged with an updated version number.
Instead of using a single server-side repository to act as the “central” codebase, it gives every developer their own server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one.
GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.
Pull Request at any point during the development process to initiate discussion about the commitsdeploy changes to verify them in production and merge the code into the master branch