I am aware that beej's guides are typically quite comprehensive, but the vast nuances of git truly eluded me until this.
I guess Jujitsu would wind up being a much slimmer guide, or at least one that would be discoverable largely by humans?
The universe doesn't owe you an easy 10 minute video solution to everything, it's an annoying educational expectation that people seem to have developed. Some things are just that difficult and you have to learn them regardless.
I can teach someone who has never even heard of source control how to use Perforce in about 10 minutes. They will never shoot themselves in the foot and they will never lose work. There are certainly more advanced techniques that require additional training. But the basics are very easy.
Git makes even basic things difficult. And allows even experts to shoot their face off with a rocket launcher.
Git sucks. The best tool doesn't always win. If MercurialHub had been founded instead of GitHub we'd all be used a different tool. Alas.
How do I undo a change and get it to other people on the team?
- follow up, What happens if someone has made an unrelaydx change since?
- someone has committed an enormous change and I want the commit immediately after it but the enormous change doesn’t affect me. How do I get that single file without needing the mega change.
- someone has committed a mega change and pushed it to main, and it’s busted. How do I put my perfectly functioning feature in while i wait for the west coast to wake up and fix it?
I don’t need an explanation on how to solve these issues, I am perfectly able to. But these are daily workflow issues that hit requires you to use external tools, and change entire development processes to work around. And trying to skirt them is a guaranteed one way ticket to a busted workspace
in my 8 years of using git as a primary tool for vc, i have not once run into confusion on how to switch branches, create branches, prune branches, sync remotes with locals, and other common workflows.
does that mean i have only dealt with simple merges or haven't fucked something up bc i did not understand something and made things way harder than necessary (merging/replaying 50 commits vs squash rebase workflows, for example).
and no, you don't need to 'fetch' before you switch, fetching is only relevant if you're needing to bring in remotes or you're preparing for merges etc.
someone committing bunk to a main branch or something considered a production branch is not a git problem -- that's just bad development practices, and the onus is on the developer there to not do that and to understand why it is bad.
as for your other complaints, these are much more easily managed when the developers are not just arbitrarily commiting to branches without any strategic thought, but to point out, a lot of those problems are solved via working with commit hashes and branching, assuming you have already plugged the leak that is committing breaking changes to a main branch.
why are breaking changes that are mega changes even making it through to main?