Funny what you can do with Git at a lower level. š
Nice to see there are still people out there keeping in mind the "let's not put all our eggs in the same basket". This is especially important for systems with such vendor lock-in as GitHub. I'm a bit less convinced about replacing Git itself for now.
Since I've seen this argument floating around more than once, it's nice to have a properly done rebuttal of it. This is nicely done, listing the own bias of the author, still in the end that shows the logical flaw of the argument.
Neat git trick, could be useful from time to time.
An often forgotten feature of git. That said it is very convenient when we need to juggle several branches at the same time. This can save some time and space.
I tend to agree with this quite a lot. Git submodules tend to create lots of strange issues and rather bad developer experience. Even worse it's not necessarily spotted straight away, you notice the real pains only after having invested in it quite a bit. There are alternatives worth exploring though.
An old piece, I sometimes like to revisit the basics so here it goes. A very nice explanation of how Git is built and how it works internally. It's of course a simplification in some way but close enough to have a good mental model of what goes on behind the commands we use.
Obscure feature definitely but we're happy it's there... maybe one day it'll indeed allow to have much more independence from the code forges.
Nice list of things to keep in mind when working on projects, even small personal ones. This greatly improve maintainability in the long run.
Now this is a very interesting trick for git. This way large reformatting commits are less of a concern when exploring commit history.
Looks like a neat and light option to self-host git repositories.
This explains fairly well the reason why I spend so much time doing git rebases or push for more readable history in branches submitted for reviews. It helps a lot with the reviews and with finding root causes of issues later on.
Good advices on using tags properly for versioning.
Always wanted to try this particular way of dealing with patches. But none of the projects I contributed to so far work in that mode.
This is welcome changes in the git cli interface which I noticed... that said I'm already so used to the old method it'll take me some time to adjust.
A good reminder of why you don't want to mess too much with the VCS history for systems with long term maintenance and several stable releases.
Very nice set of tip and tricks for git. Quite a few are probably known to the more advanced users but still there might be one or two for everyone's taste.