Synopsis
Lately I have been asked to look through Gateware Repositories from different users, with different interesting problems.
One thing I keep coming across is work on the main branch.
I realize it’s probably people who doesn’t know better, but to the trained eye, it’s really painful to watch.
The problem
There are a whole slew of problems with this approach; let me just list a few:
- First and foremost, your history gets all tangled.
- It’s way harder to locate breaking changes…
- Was it something that you did?
- Was it the last pull from upstream?
- It can lead to lots and lots of merge commits, further adding to the confusion.
- Creating PR’s for the gem you’ve made is impossible…
- No self-respecting Maintainer is going accept something filled with merge-commits.
- You’re not isolated, i.e. anything can affect you.
- etc. etc.
The better way
Allow me to paraphrase Greg Kroah-Hartman: Branches are cheap; use branches…
Ok, so you just forked your Repository, but resist the urge to just start hacking away!
The very first thing you do is git checkout -b devel and now your very own branch is created and you’re switched to it.
If in doubt, git status will tell you where you are.
Tip
If you use a shell like fish, the prompt has built-in support for git and will display your branch right at your fingertips.
Keeping up with the world
Right, you did a bunch of commits on your devel branch, but now you want to have a look at what has happened in the world since the last time you looked. git fetch origin main will let you do that. See anything interesting?
git pull origin main will get the latest updates, but note how those upstream commits don’t affect you (yet)… You’re isolated in the relative safety of your devel branch.
Depending whether your working directory is “clean” or not, you should either commit or stash your changes in preparation for the next operation.
From here, you can either cherry-pick if you want to check out a commit or two, or you can choose to rebase your branch, i.e. move the whole branch on top of the incoming changes. Remember, you can always back out of a commit with git reset --hard HEAD^1 if you don’t like it.
Final words
This post was in no way intended to be a primer to the world of Git, but more like showing you that there’s a better way to avoid many of the pitfalls you may inadvertently work your way into. Google, CoPilot and Stack Overflow have oogles of further information, if you’re interested…