git: git flow basics

Git flow is a superset of the Feature Branch workflow. It’s particularly useful for larger projects such as those with a regular release schedule.

The basic ideas are:

1. The master/main branch is for release only. No development should occur here.
2. From master/main a develop branch is cut.
3. Development work follows the Feature Branch workflow, but targets develop instead of master/main.
4. When releases are ready, a new branch is cut from develop and prepared. The release branch is prepared and merged into master/main (and, if any changes occurred, back to develop).
5. If a hot fix is needed, a branch can be cut directly from master/main, but when it’s merged into master/main, it’s also merged into develop to keep the two branches aligned.

Another feature of the Git Flow is that it provides a convenient illustration of when it’s appropriate to merge vs rebase:

For feature branches - rebasing and squashing commits offers a clean, organized way to communicate the changes made during development. I.e., it’s a perfect place to practice writing better commits. Remember, when it comes to rebasing, the assumption is that the code is private:

Note: Don’t push your work until you’re happy with it

One of the cardinal rules of Git is that, since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. In short, you should avoid pushing your work until you’re happy with it and ready to share it with the rest of the world.

Said even more explicitly:

Do not rebase commits that exist outside your repository and that people may have based work on.

If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.

Source

It’s worth noting that Git Flow is not for every project and, in fact, runs counter to the suggestions put forth by Kim et al. in Accelerate where frequent commits directly to the main branch is recommended (supported by robust testing).