git
Once upon a time, in digital electronics design, we were used to moving huge zip files around including project data, code and all ancillary stuff along with it. We were doing backups, snapshots and versioning our code with help of compressed files. That’s the way it was, I knew that time, and you, young reader, would not believe me if I told you about the whole picture. This is not acceptable anymore.
Today we have (well, we already did 20 years ago, but, you know, we were electronic engineers, not coding experts after all) tools to handle the situation. We have control version, we have git, and this more than we need to follow changes in our code (and our documentation, bibliography, etc.). Sure, we need a bit of discipline to use it in meaningful way, writing clear commit messages, committing correctly, creating clean histories, using the right branching model and learning how to use #git in a collaborative way. Following best practices is something that, as for today, should be accessible to any engineer, provided he is using the right tools.
The point here is how to interface git. In my experience, most hardware engineers (but not only) just do basic clone, push and pull, creating linear histories. Simply put, they use git as a backup system, with huge unrelated commits. They use git because they must use git, as anyone else is doing, but without any of the associated benefits. No history read, no diffs, no topic branches, no rebasing, no merging, no nothing. The reason is they’re using the command line interface (#cli) to git. Using git in the command line is fine, provided you’re fluent with clis, with a good shell and its plugins, and you have a very good long term memory. No one remembers how to interactively rebase 10 last commits on top of another branch, squashing history. Full stop. And no one will commit every 30 seconds if it takes one minute. Forget about. This brings to the clone/pull/push/that’s it step slope most people is faced to when they use git. And, unfortunately, this is the end of using git proper.
Now, what to do about ? #modernhw requires using a GUI to manipulate your git repositories. This will provide you with a lot of benefits, among them, a clear overview of where you are in your git history, your current status, and most importantly, where you’re going from this point. Which GUI to use ? Don’t expect an answer from me. The one you feel more comfortable with is the right choice. No matter what, provided it is #freesoftware. Spend as many time as you need mastering its usage, you’ll be rewarded afterward.
Personally, as I’m using #emacs, my not that original choice goes to using #magit. Magit is a front end application to the command line git, closely embedded within the rest of my workflow. As usual, once one gets used to its way of doing things, it’s really fast to perform any git operation in a few seconds. Within a few keystrokes, it is possible to get the status, log, remotes, branches and doing the difference between to different versions. It gives access to complete much more sophisticated manipulations in less time that it takes to tell about. Try to achieve the same using the command line (you will, but it will take ages). The key here is the time it takes: if you need longer to git than what it takes to think about, you’re using git the wrong way. You’ve been advised.