There's one thing I'd add, which is probably just an extension on the topic of Branches with respect to this tip: "Integrate Continuous Integration (CI) for building software."
I think it's very common to misunderstand Continuous Integration to mean "run automated tests on every commit to the master/production branch". Which, in a trunk-based-development environment is a partially complete definition - you definitely want to do that, but there's a lot more to it.
However when utilising git branches, it's important to execute your CI pipeline against all branches for every commit they receive. This ensures that your branches that, from the moment of their creation are slowly slipping away from master, are kept in line by being subject to the same, continuous, scrutiny. This commonly includes performing a merge with master in the CI agent to verify everything hangs together nicely.
This goes hand in hand with rebasing against master constantly.
Doing these two things means that merging back into master becomes super boring. You submit a PR, potentially for a code review, and then everyone feels comfortable about hitting merge because they know the branch plays nicely with master.
Waiting until the merge into master to verify that everything works together just kills your feedback loop. It could take you days to discover a regression that could have been identified in the first commit.
I've also found that businesses respond interestingly to this approach too, because when they have to pay for CI agents to run branch builds, they're suddenly really interested in keeping the number and lifetime of branches short. Which is something we should all want anyway ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a really cool collection of tips :)
There's one thing I'd add, which is probably just an extension on the topic of Branches with respect to this tip: "Integrate Continuous Integration (CI) for building software."
I think it's very common to misunderstand Continuous Integration to mean "run automated tests on every commit to the master/production branch". Which, in a trunk-based-development environment is a partially complete definition - you definitely want to do that, but there's a lot more to it.
However when utilising git branches, it's important to execute your CI pipeline against all branches for every commit they receive. This ensures that your branches that, from the moment of their creation are slowly slipping away from master, are kept in line by being subject to the same, continuous, scrutiny. This commonly includes performing a merge with master in the CI agent to verify everything hangs together nicely.
This goes hand in hand with rebasing against master constantly.
Doing these two things means that merging back into master becomes super boring. You submit a PR, potentially for a code review, and then everyone feels comfortable about hitting merge because they know the branch plays nicely with master.
Waiting until the merge into master to verify that everything works together just kills your feedback loop. It could take you days to discover a regression that could have been identified in the first commit.
I've also found that businesses respond interestingly to this approach too, because when they have to pay for CI agents to run branch builds, they're suddenly really interested in keeping the number and lifetime of branches short. Which is something we should all want anyway ;)