If you use something frequently you should know it in-depth. It applies to tools (git, VSCode), frameworks (Spring, Django, whatever), infra (kubernetes, docker). otherwise you're missing out.
Hard agree. I love this mindset! If you put a tool in your toolbag you should know how to use it.
Git is definitely abstract and hard to get the hang of but totally worth it - pays dividends in terms of the options it puts at your disposal. And the stimulating nature of learning how it works so that you can think for yourself to figure out a solution, instead of just memorizing 3 commands and running to AI for help when you get a little stuck.
Version control is one of our main tools for interacting with other developers. Having a rich understanding of your version control software often helps to find solutions and workarounds for problems which would otherwise result in needless conflict.
I would just add `git rebase -i` to the mix. Very useful to clean up a work branch before submitting it for others. Sometimes you just need a bunch of "wip" commits, e.g. testing CI scripts, deploying a optimization on the side for further testing, etc. and rebase is a must if you care about the commit log.
You forgot to include an explanation of what rebase does, which is important for knowing when to actually use it, instead of just specific goals you might have.
sure but is it enough to avoid using it though? I don't like to get screwed in business, but I don't avoid the screwdriver in my toolbox when I need one.
This was my approach for my first few years of git. I always tried to approach git via its commands, and I horribly failed - until I finally took a little bit of effort to understand how git actually works under the hood, which really made it click for me.
For anyone who has ever spent a modicum of time (e.g. while getting a CS degree) trying to understand datastructures, it's probably really straight-forward to "get git". The datastructure underneath is really quite simple. A branch is a pointer to a commit, a commit is a pointer to a tree, a tree is a list of pointers to other trees and files. That's already pretty much all there is to it.
Once the datastructure of git is understood, the commands start to "make sense" on their own - at least most of them. They still have tons of obscure options that one doesn't realistically need in a daily work flow, but the general idea what the commands do (and how to recover from screwups) was, at least for me, pretty simple after understanding the datastructure.
haha this is a bit of a sad take in my opinion, because of the value that I feel that comes with understanding how a tool like Git works behind the scenes, but seems to be several folks here who feel the same way you do
I feel the same way. All of git's weirdness seems totally reasonable once you understand it on its own terms. It doesn't even take a ton of understanding to get that that point either.
It's not a sad take. There are many roles in tech and I'd encourage those trying to make things to focus on that. You can get extremely far with 4 git commands. Even in a production team environment, you may only need to ever add in the merge workflow.
I agree with you. My typical workflow is: update master branch in Visual Studio, create a new branch off of the master, work on it, when ready use GitGUI to commit and push, then do a merge request in GitLab (we use GitLab). When approved, I push the branch to master. From time to time I need to update my branch, either because I make some code changes, or because my branch a few commits behind the master.
Would I like to know more about the underlying ideas of Git. Yes. But the time it would take me to do that is time I can spend on other things, like the stuff I am actually paid to do. If I become a git guru, I might get a pat on the back, but more likely no one would care. If I deliver more stuff, people who use my stuff actually appreciate it.
The reason it's sad to me is because there is so much more to explore, to be stimulated by, to be able to apply in a way that makes you think out of the box.
Maybe a lot of people don't care about that, and I guess everybody has their threshold, where as long as they know the minimum required to do their job they can stay in that comfort zone typing the same commands over and over.
The only winning move is to learn your tools and develop a mental model of what they're doing. You know, like everything else a programmer needs to know.
