This is my own take on a workflow for Git.
It is aimed at working on a software project within a team of max. 10 developers or solo using version control to manage their codebase.
- Master must always be deployable.
- Changes made through feature branches.
- Merge into master.
- Release tag.
At the time "Git-flow" is the defacto Standard. But I would argue it is way too complicated for what most of the teams want to archive. I would even go a step further and say it is contra-productive.
One of this reasons for moving away is that the git-flow process is hard to deal with in a continuous deployment model. It looks like that Git-flow works well for products in a more traditional release model, where releases are done once every few weeks, but that this process breaks down considerably when you’re releasing once a day or more.
That is why I looked at the established alternative workflows like "GitHub Flow" and "GitLab Flow" and build my own based on these best practices.
# Update Master.
$ git switch master
$ git pull origin master# Create feature branch with descriptive name or ticket ID if given.
$ git switch -c my-new-featureImplement the feature.
# Commit your changes with a description and ticket ID if given.
git add -p
git commit -m "Add changes"# If the feature branch lives longer keep it up-to-date.
# Use rebase only if the feature branch is not pushed yet otherwise use merge.
git fetch origin
git rebase origin/master# When the feature is complete use a Pull-Request to discuss and approve changes with team members.
# If there is no PR system in place merge with the following commands.
# "--no-ff" preserves feature history and makes it easy to revert the feature.
git switch master
git pull origin master
git merge --no-ff my-new-feature# Set a tag if you deploy master
git tag v1.0.0