Sauter Git Workflow - sauter-hq/git-guidelines GitHub Wiki

The Sauter Git Workflow bases itself on Git Flow which is well appreciated by different teams around the world. It turns out that Git Flow is a workflow near of most software developer problematics.

We tried to stay tight to Git Flow principles, while still tuning small points that were not optimal for Sauter's software lifecycle. And that's the point, each situation is different, even within Sauter, so don't hesitate to tweak the guideline to your particular problem. You could add pull-requests before finishing a feature, you could implement this workflow over multiple repositories or simply use it as-is.

---

Software Developer Workflow

• Clone Repository
• Initialize Git Flow ( i.e. Note that Git Flow should be initialized after each clone, as it is a local configuration to automate the workflow.)
• Working on a new feature
• Working on an existing feature
• Finishing a feature : merge it back into develop
• Merge a feature branch in another feature branch
• Workflow overview and examples
• FAQs

Project manager or repository maintainer workflow

• Creating the initial repository
• Prepare a release for the Quality Assurance dept.
• Make the final release for a version
• Make an hotfix

Special workflows (team dependent)

Here are some workflows, which are found in some teams to be a good practice
They can also be transferred to other teams

• [Working with hotfix candidates (CASE Engine team)](./Sauter-Git-Workflow-:-CASE Engine-Working-with-hotfix-candidates)