~2 min read|
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:
main branch is for release only. No development should occur here.
develop branch is cut.
develop instead of
develop and prepared. The
release branch is prepared and merged into
main (and, if any changes occurred, back to
main, but when it’s merged into
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
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.
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).
Hi there and thanks for reading! My name's Stephen. I live in Chicago with my wife, Kate, and dog, Finn. Want more? See about and get in touch!