Git Black Arts
Scratch the surface
I hear quite often complaints like "Git is too complicated".
If you're thinking about saving the daily and push to some central repo, it could just be the case.
But maybe not.
The Dinosaurs
Not if you've been doing some serious work with Subversion. Better if you used it with a language like Java, where a shallow dir is not all you need, and you've seen those nightmarish nested directories, all containing an hidden .svn directory with ... important data in it.
Or maybe even if you've been working with CVS, nothing more than a light abstraction on top pf RCS.
Those also were the good tools, the open ones. I don't even want to get started with legacy, proprietary monsters from the past where it was possible that the hashing function would run into conflicts when two different files produced the same hash.
Perversions
I recall a project @somecompany that was developed for @somecustomer. @somecustomer had it's own CVS server, where they would expect the deliveries. @somecompany had a stong workflow, and strong developers bound to working with Subversion.
The efficient way to work with that particular customer ended up being checking in .csv hidden directories to the Subversion project, just like regular source codes.
The happy case was easy to cover: of course! You're left wondering what could possibly go wrong, instead, if you had to manually 'rebase' changes in CSV to the Subversion repo...
The Complaints
To be fair, to begin with, when people says that Git is complicated, I'd just say no, it actually isn't. If all you have is a central repo, you do local development and push up changes at the end of the day, it's just about the same workflow. The name of the commands might sound a bit off, or strange, but complaining about that is a bit childish.
As a grown up, aren't you supposed to have alias and scripts for operations that you repeat all the time, possibly in a jargon that you speak, or haven't you ?
Should the unix gods create a command called push-current-branch for you alone, or maybe you realize that, if it makes it memorable to you, you should just throw the commands in a script and use that instead.
If you say: "Git is difficult", what I hear is: "the shell is difficult". And still, it could be.
But no, sorry, I won't be using a GUI, that does not make it easy, it just makes it obscure, the you'll need to trust whatever command your drag'n'drop has accidentally produced with the intention to make you (maybe) happy.
The darkness is lurking at you dragging the mouse on the drop-down options.
Enlightenment
There is a ton of literature on the fact that in Git Merge is done locally. Still, you won't appreciate it enough, unless you've worked with Subversion and made a merge when the network was slow, destroying the legacy of your project in the process.
Also, if you're not already biased against Merge for the experience that I described above, you should still favor Rebase over Merge, this is also a main point of Git.
I am not the best, nor the only one to explain why, but I can but notice that most fellow developers don't use it and end up wasting time with huge merges that are avoidable most of the time.
At the price of a slightly deeper level of thinking, once we get away with the daily routine, we have a tool that provides real superpowers.
Let's say we have a backend X that we implemented for a specific purpose. We keep using it, and we extend it. As while we're at it, we fill in with fixes, and features.
Then one day, we decide another use-case for that fantastic, scalable, secure piece of backend of ours: shall we copy-paste the whole codebase into a new repo, just to add some feature and end up with 2 projects to maintain?
The answer is better no: branches are there for a reason.
Possibly, the new use-case will have a different Remote where we push the changes. But still, it's one codebase, two different 'master' branches, with two distinct purposes.
It starts with 2, but it can become N: each use-case has got its own remote.
If you find a bug in the code-base, you make a bugfix branch, and propagate to the different branches.
And if it's too bad, you don't have a single branch, but a couple of commits, you can still cherry-pick them on top of your customers' branches.
The remotes could be anything: from a customer's repo to a CI pipeline that, with a post-hook commit builds the project and sends you a report. It could be simply a backup remote for one or all of the branches you have.
Is it complicated ? Not if you don't need it to be. This is a real masterpiece in scalability: the more you ask, the more you will get from it.
Please stop complaining that Git is complicated, maybe simply is not what you think it is, then show us how much more easily you would do what it does...
[git] [java] [backend]