I think some people are getting confused about terminology between Trunk Based Development[1], Git Flow[2], and GitHub Flow[3]. TBD and GitHub Flow are nearly identical, basically if you use TBD on GitHub you use GitHub Flow. Git Flow (not GitHub Flow) is a model that is all about cutting releases, and supporting bug fixes to releases. Git Flow is nonsensical when doing Continuous Delivery[4] of a web application.
If you are delivering web app code to production every day, it doesn't make sense to cut versioned releases, with for example semantic versioning, instead you just release the code that has passed tests. It also doesn't make sense to have hotfix branches, because there is only one version in production[5], and you release every day, so there is no need to backport a fix to older versions, or do anything special to get a fix out quickly.
Trunk Based Development has branches. If you are working with a team you pretty much never want to commit straight to master. The difference is that in TBD the branches are short-lived and only exist for code review purposes.
This is what TBD would look like with GitHub and GitHub "forks".
git remote -a
origin git@github.com:<your company>/<repo>.git (fetch)
origin git@github.com:<your company>/<repo>.git (push)
<github username> git@github.com:<github username>/<repo>.git (fetch)
<github username> git@github.com:<github username>/<repo>.git (push)
git checkout master
git pull # make sure you are starting with the latest master
git checkout -b my-cool-feature # create a branch for you change
vim <file>
git add <file>
git status # check that all expected code is staged
git diff HEAD # review your changes
git commit # write a meaningful commit message
git fetch # get the latest changes from origin
git rebase origin/master # put your changes on top of the latest changes from master
git push <github username> my-cool-feature:my-cool-feature # push to a branch on your "fork"
# Open a PR to merge from <github username>/my-cool-feature to origin/master
# Once the PR is approved, use the GitHub UI to merge the PR into master
git checkout master
git pull # pull down your code that just merged to master
git branch -d my-cool-feature # delete your feature branch
[4] I'm defining CD to mean delivering to production at least once a day.
[5] Unlike on-premises software, with a SaaS product you only have two versions: (1) what is in production, and (2) what is going out to production (in staging, canary, etc.).
Like I said in my other downvoted post... too many TBD zealots look at big companies that use it sans branches, and assume that it is the one true way, instead of understanding the larger picture (branches outside of git suck, these companies don't use git for various reasons)
Many of Google's 25000 Trunk-Based-Developers use Git on their local deevloper workstations. They choose their own workflow on their own machine, and then cooperate with the Mondrian submission rules when attempting to get their commit(s) through code review and automated tests/lint/findbugs etc.
If you are delivering web app code to production every day, it doesn't make sense to cut versioned releases, with for example semantic versioning, instead you just release the code that has passed tests. It also doesn't make sense to have hotfix branches, because there is only one version in production[5], and you release every day, so there is no need to backport a fix to older versions, or do anything special to get a fix out quickly.
Trunk Based Development has branches. If you are working with a team you pretty much never want to commit straight to master. The difference is that in TBD the branches are short-lived and only exist for code review purposes.
This is what TBD would look like with GitHub and GitHub "forks".
[1] https://trunkbaseddevelopment.com/[2] http://nvie.com/posts/a-successful-git-branching-model/
[3] https://guides.github.com/introduction/flow/
[4] I'm defining CD to mean delivering to production at least once a day.
[5] Unlike on-premises software, with a SaaS product you only have two versions: (1) what is in production, and (2) what is going out to production (in staging, canary, etc.).