Learning git is very easy. For example, to do it on Debain, one simply needs to run,
sudo apt install lazygitThis has been the best git tutorial I’ve come across so far. Nicely interactive and gamified. https://learngitbranching.js.org/
Git is a great invention but it has a few design flaws. There are too many ways to confuse it or break it, using commands that look correct, or just forgetting something. I ended up writing simple wrapper script codebase to fix it. Since then no problems.
It was conceived for experts so the new user experience is shit and the UI is not intuitive. But it has become such a widespread standard that it is very hard to completely overhaul the UI.
Yes you couldn't change something so widely used. Look what happened with python 3.
Fortunately there's already a tradition among Git users of building a UI on top of the git UI. My project is just a slightly better version of those. It lays a simple sensible interface on top of the chaotic Git interface.
sublime merge is pretty great, but having a working familiarity with the underlying tool is invaluable when shit inevitably goes sideways while collaborating
If you can't use git I don't see how you're gonna do with other things. It's dead simple.
It's not THAT complicated but I wouldn't call it dead simple. When you understand how git works internally yeah it's pretty simple but people usually start with the idea that it's a tool to put your code on a server to synchronize with other people and only later learn that you have both a local and a remote (or multiple remote) tree and how the tree really works.
I think the problem is most git 101 tutorials teach it wrong, IMO the best git tutorial is this: https://wildlyinaccurate.com/a-hackers-guide-to-git/
Unfortunately it's pretty dense so it's gonna scare off a lot of newbies.
If it was dead simple you wouldn't need to learn 10 new concepts and google commands regularly even after using it for a couple of years. You probably forgot how you struggled at first. I have taught it multiple times and I see how beginners struggle.
I would actually say it's VERY complicated but in daily work you probably need like 5 commands and those aren't hard at all.
Its not dead simple but its also not extremely complex.
I'm currently working with some interns and there's just concepts they were never exposed to. Without decent mentoring, git can be difficult because a lot of the workflow does come with experience.
That being said everyone needs to stop acting like its an impossible task to properly do source control. There is some truth that if you don't care enough to do your source control, you don't care enough to write decent code. Its not a moral failing, just take some pride in your craft.
Show the newbies how to care and they'll care enough to want to do it right. Measure twice, cut once and all that.
It's definitely not simple to use but I agree that the conceptual model it represents is straightforward. I think a lot of the problems people have with git come from not understanding the underlying data structure before learning how to manipulate it.
Great meme, and I'm sure op knows this, but for anyone else who is curious...
007 in theory means:
- 00: you have already committed your code to your local code base
- 7: When you try to merge your code with everyone else's there are 7 files that others have worked on since you last refreshed your local code base.
To resolve this, you need to go file by file and compare your changes with the changes on the remote code. You need to keep the changes others have made and incorporate your own.
You can use
git diff file_nameto see the differences.If you have made small changes, it's easier to pull and force an overwrite of your local code and make changes again.
However multiple people working on the same files is usually a sign of organizational issues with management. Ie, typically you don't want multiple people working on the same files at the same time, to avoid stuff like this.
If you're not sure, ask someone that knows what they're doing before you follow any advice on Lemmy.
If I get a big conflict and I know my change is trivial, I feel perfectly okay doing git fetch git reset --hard whatever and then reapplying my simple change as a new commit. Sort of a bootleg rebate.
I hear what you're saying.
First, I hard disagree with you. Overwriting my local version of code is a parachute - not an ideal landing, but better than merging by hand.
Also, my comment was not an attempt to teach everything about git, just to explain what is happening in simple terms, since git requires a lot of experience to understand what those messages mean.
It's the thing you use to create a local copy of the main code base, and then merge your changes back in.
OP hasn't done anything, and there's 7 conflicts between his code and main. Presumably because someone else merged their changes in the time between when OP pulled his local copy and tried to push his (non-existent) changes.
Pro tip: If your code gets flogged by git, you can always get revenge with
git reflog😉
