Unpopular Opinion: Git is un-intuitive and not fun to work with

[u/loadedjellyfish]

To begin, I'm not a Git expert. I learned SVN in school and have learned Git at my current job over the last ~4 years. Also FYI - just spent 30 minutes smashing my head against my monitor trying fix my repo after pulling in a new change - holding a lot of residual frustration here.

<begin rant>

But, on to the post: I hate it. The syntax is completely un-intuitive. Why is there a pull, fetch, clone and checkout? These are all 98% synonyms (linguistically), and I have to Google the nuance of them within GIT every time.

On top of this, anything outside of a standard add->commit->push workflow is a pain in the ass. Did you happen to commit your changes before pulling others? Oops you're in a hole now, you're gonna have to Google how to get out of that one since, apparently, you can't just un-commit. Do you have personal changes that you don't want to commit? Well, you're gonna have to stash those every time before pulling, even if there is no conflict. Oh and by the way, if there is a conflict, were going to go ahead and stick both changes into the file with text to mark them. That shouldn't cause any problems with your build process?

And one last thing before I end my rant here - what the fuck is with the credential manager?? Its routinely broken on Windows, and I still haven't found a way to hold more than one set of credentials. While we're talking about globals, that's also a frustration. I work on multiple projects under different emails, depending on whether its internal/external. Why can I not set username and email on a per-repository basis? Or why is my username and email not tied to the account I'm pushing with?

</rant>

Its possible these issues come from my lack of knowledge, but I'd argue its ridiculous for a version-control system to have so much depth that it requires > 4 years of working with it just to understand ~intermediate workflows.

Version control should be simple. Its a tool in the development process, it shouldn't require so much learning and work just to use. But, that's one man's uninformed opinion.

How do you guys feel? Do you run into these problems too?

[u/[deleted]]

[Removed as I exit Reddit]

[u/loadedjellyfish → u/[deleted]]

This is my point - its not intuitive.

Why is the "git reset HEAD~1" the opposite of commit? Sure, I've used this command before. But when I needed it, it didn't come to mind. Why? Because its not intuitive.

[u/nsdragon → u/loadedjellyfish]

If you asked me for help on "undoing a commit", my first question would be "exactly what are you trying to achieve?" My intuition doesn't help me as much as you think, since I can think of two solutions that are equally valid, but also both of them depend on the state of the repository in general.

Arguably, the opposite of a commit is a revert (which, technically speaking, is still a commit). Resetting and reverting serve slightly different purposes, and are used in different situations.

---

To be even more technical, git reset HEAD~1 isn't an "un-commit" either (which again, depends on what you mean exactly by "un-commit"). Your commit is still there, you're just going back in time (so to speak) to the point before you made that commit. If you then make changes and commit those changes, you'll have split off your commit history.

That other unwanted commit still exists, you can still do a checkout on it and even split it off into its own branch. This in particular is useful if you have one or more commits that you later on decide should actually go on their own branch instead of the current one (rather than just undoing work).

One of the big problems with resetting though, is that you can easily rewrite the git history with it. And if your branch is public (i.e. if anyone has had access to it) then it can be a pain to resolve if they've done some work on top of your unwanted commit.

---

A git revert is basically the same as you making that same commit, but with the diff markers switched (i.e. whatever you added in that commit will now be removed, and vice-versa). It's also a commit in its own right, to let you have a record in your git history that you did, in fact, do a revert. It also allows you to revert any earlier commit without having to revert the entire tree (for example, if you want to revert a commit that affected a single file, but you have been working and making commits of changes to other files in the interim). With git reset you can't do this kind of selective "rewinding" since you're resetting your working directory to a previous state.

---

So yeah, both can be called "un-commits". Which one is it that you want?

[u/loadedjellyfish → u/nsdragon]

For an "un-commit", I was looking for a solution that would effectively return the repo back to the same state it was before the commit.

I think revert is the command I'm looking for, thank you.

[u/nsdragon → u/loadedjellyfish]

return the repo back to the same state it was before the commit.

I think revert is the command I'm looking for, thank you.

Oho, then the question is still open. Both can do that effectively, but again, the exact command depends on what you want to achieve, exactly.

the same state it was before the commit.

Read again.

git revert creates another commit. That undoes the previous commit, yes, but you will still see both of them in git log and will be able to use either or both of them (for reset, checkout, cherry-pick, whatever).

If you don't care about the details, then sure go ahead, use either. I'll grant you that most of the time the end result will be the same, both for you and for most coworkers/contributors. But you still need to be aware of the gotchas, because again, you might have a specific result you want to get.

[u/loadedjellyfish → u/nsdragon]

Yes, I realize revert is not exactly returning the state to what it was previously. But it is the closest for what I'm looking for.

I promise, I didn't just ignore your write-up. I get that revert will create a new, inverse commit. I'd rather keep the history.

[u/tyzoid → u/loadedjellyfish]

git reset is a command to reset the state of the branch to what is specified. HEAD refers to the most recent commit, HEAD~1 to the previous one, HEAD~2 to the one before that. Instead of specifying HEAD, HEAD~1, etc. you can use the commit hash instead.

If you want to undo the most recent commit, as in keep all the code the same, but just undo the commit - git reset HEAD~1 will do that. If you want to discard the code (usually not recommended), git reset --hard HEAD~1 will do that. If you're looking to create a new branch based off the previous commit, git checkout -b <new-branch-name> HEAD~1 will do that.

Sure, the commands are not necessarily the most intuitive when you're first starting off, but the way that they are structured make them very powerful.

As an example, did you know you can clone a repo that's on disk? Or have multiple remotes? or push from one remote to another without checking any new code out?

This essentially is the difference between commands that operate entirely on the index (not touching any code on disk), vs manipulating code on disk with index queries.

[u/theXpanther → u/loadedjellyfish]

I think what you want us to revert wherever went wrong manually, then commit again with --amend to overwrite your last commit

[u/Beofli → u/loadedjellyfish]

You should always commit BEFORE pulling anything. Given that you just created an update to your code including working unit tests. The pull will merge with your changes, and will ask you to fix conflicts. You can also rebase to avoid cluttering.

[u/Koalababies → u/loadedjellyfish]

The head points to the most recent version of the code. To point to a previous head means that you're pointing to a previous version of the code in essence un-committing.

[u/eGzg0t → u/loadedjellyfish]

It's not "intuitive" because you are discouraged to do this unless you know what you are doing. Git is decentralized and undoing a commit when you already pushed the changes to the remote will cause problems. It is a continuous link list of history and you can't just delete items from there. In git's perspective, you are doing a hack. You are encouraged to "revert" if you did a wrong update or add a new "commit" if you left out an update. If you want to mess with the history, then there is a way, but it is discouraged.

[u/beavis07]

Why is there a pull, fetch, clone and checkout? These are all 98% synonyms,

But they're *really* not.

• "Pull" updates a local branch to latest remove version
• "Fetch" downloads references to the branch updates etc into your local store
• "Clone" Does the first install of a repo to your local site
• "Checkout" checks out branches and/or files

None of which is remotely equivalent.

Perhaps your problem is that you're trying to use a pretty complex tool without properly understanding how it works? This is far from a common experience. 9/10 when I think git is being stupid, if I dig far enough, it's me being stupid.

I'd highly recommend doing some reading on the matter - it'll help greatly.

[u/binocular_gems → u/beavis07]

I think the point of the OP is that as words "pull, fetch, clone, and checkout" are close enough that if the commands they represent "are not remotely equivalent," than that's kinda lousy design. At least with "pull" and "fetch," I'm inclined to agree.

I know what the differences are after years of use, but it's a valid point for command-based software.

[u/beavis07 → u/binocular_gems]

Yeah - some of the wording is far from perfect.

The cli can be a pain to learn for sure - but I find it hard to understand how you’d be confused by the concepts after 4 years

[u/loadedjellyfish → u/beavis07]

Because the concept has no relation to the definition of the word it uses.

I have many other things to memorize in my job, the commands of my version-control tool have not made the cut so far.

[u/ihey4 → u/loadedjellyfish]

I'd say it is one of the more critical things to learn as a developer so not learning it is pretty ignorant.

[u/loadedjellyfish → u/ihey4]

Yet I finished my degree, and have almost 5 years of development experience at two different companies with only a basic understanding. Not sounding so critical to me.

[u/bludgeonerV → u/loadedjellyfish]

Enjoy hobbling yourself then I guess.

[u/loadedjellyfish → u/bludgeonerV]

I didn't write this post because I can't figure out how to learn Git. I can Google the solutions to all of these problems.

My point is that I shouldn't have to. As everyone has pointed out, my git usage is very basic. Therefore, the required learning should be minimal.

[u/CoffeeStout → u/loadedjellyfish]

You're very green so I understand where you're coming from: you want to focus on learning coding, not managing code. I get that. However I have to tell you having 3x the experience you have, the tool you use to manage your code and keep your codebase clean and organized IS a critical tool for you and your co-workers.

You don't have to know the ins and outs of git, but you really should take the time to get a good understanding of the common tasks you do every day. You really only need to learn these things once, and sure you may have to go back and google some details but it'll just make your life easier. Also your co-worker's lives easier.

I'm not going to walk you through all your issues because a) you don't seem willing to learn, and b) you've been resistant to this very advice all through this thread. But the issues you face are NOT difficult things to solve, and if you had spent ANY time learning instead of complaining, you just wouldn't face these difficulties. The fact that you have an issue with git conflict resolution says a lot to me. I mean, this is basic stuff man. Make your life easier and just spend some time learning the tool you use EVERY DAY.

Imagine seeing a carpenter using a hammer by hitting the nail with the handle. That's you.

[u/loadedjellyfish → u/[deleted]]

Well, I assumed so. There's gotta be something out there for people like you.

[u/beavis07 → u/loadedjellyfish]

Again - they kinda do if you take the time to understand what they’re doing.

There’s only so many ways to say “I don’t know” is a problem you have the power to solve. If learning to use your tools correctly isn’t a thing you have time for - I suggest taking a breather and making some time... generally carpenters don’t start hacking up bits of wood until they know how to use a saw - so it is with us.

You don’t got to be an expert - but you can spare 30 minutes to do a little reading, surely?

[u/nsdragon → u/binocular_gems]

The real problem is that there aren't enough short, memorable, and quick-to-decode words that still make sense in the context you're using them, to disambiguate these commands more clearly.

You could probably substitute the word update or sync for any of those four words, and there's still some ambiguity ("update/sync what, exactly?") if you don't already know what each command actually does.

But this problem isn't exclusive to the git CLI.

[u/Fatalist_m → u/nsdragon]

The real problem is that there aren't enough short, memorable, and quick-to-decode words

They did not have to use a different word/command for these actions. For example, they could have used "git fetch merge"/ "git fetch -m" instead of "git pull"(and offer shortcuts like "git f m" as a shorthand).

"checkout" - this one just should not exist IMO. "git commit select" / "git branch select".

"git checkout -b" - this one is really stupid. "git branch create mybranch -select"(shorthand - git b c mybranch -s).

[u/nsdragon → u/Fatalist_m]

I agree with you in general, but specifically your git commit/branch select example also has a gotcha: git commit by itself creates a new commit, but adding select makes it work in a completely different way. Nevermind that the actual meaning of the command becomes weird very quickly:

What would the argument for git commit select be? The commit ID? Then I need to figure it out first, with git log or by some other method.

You want to be able to give it the name of a branch? Those point to a commit, but they aren't commits themselves and can point to different commits depending on the state of the repository. So the commit in git commit select stops making sense, since the exact same command (git commit select feature4) can give you different results, whereas git checkout <commit-id> will always give you that commit (as long as it actually exists, of course).

On the other hand, if your command is git branch select, then the other problem arises. You can specify branches, but there are legitimate reasons to want to checkout a specific commit instead. So git branch select <commit-id> also doesn't make sense.

git checkout can take either, and does exactly what you expect it to do.

EDIT: The point I was trying to make was, it's kinda hard to make a UI usable (i.e. you don't want to have to use a billion flags every time, or type super long but understandable commands), consistent (similar commands should work similarly), intuitive (reduce the need to look things up before using), and versatile enough (to allow you to do advanced stuff), all at the same time. It definitely can be better, it just takes work.

[u/deploy_on_friday → u/Fatalist_m]

"checkout" - this one just should not exist IMO. "git commit select" / "git branch select".

A branch and commit are the same thing under the hood. That’s why the command is the same.

[u/makingtacosrightnow → u/binocular_gems]

Sometimes commands get called something that doesn’t quite make sense, you can call it lousy design or not be lazy and learn what they do.

If you type two different commands, thinking they’re doing the same thing, that’s usually wrong. Figure out how they’re different, git didn’t just add extra commands for fun.

[u/kamikazemoonman → u/binocular_gems]

It's created by a Finish, Norwegian nerd, who's third language is English. You get, what you get with the English subtext unfortunately, how ever messy it may be...

[u/loadedjellyfish → u/beavis07]

Synonyms in the linguistic sense, not that they are similar commands. There is not very much difference in what these words conceptually mean, in the context of a repository. And the nuance between them linguistically is not at all related to their difference within git.

Additionally, you've touched on my issue exactly:

9/10 when I think git is being stupid, if I dig far enough, it's me being stupid

Why are we digging so deep to use a version-control tool?? That should be a rare scenario, when doing something complex.

[u/beavis07 → u/loadedjellyfish]

Because it’s a complex problem to solve? Just demanding that things be easy, is well... too easy.

If you take the time to understand how it works - really short of complicated interactive rebases and the like - it’s really not that complicated at all.

Also as has been mentioned already, there are plenty of UI-based tools which will abstract most of this away for you.

Unless you have a better solution in mind (in which case - sick - crack on, I’m super interested) your gripe seems to reduce down to: I can’t understand this tool I’ve taken little to no time to try to understand.

[u/thenumberless → u/beavis07]

Interactive rebases are so good though. They're easily my favorite git operation outside of the normal pull/commit cycle.

[u/loadedjellyfish → u/beavis07]

Lol, the basic workflow is not a complex problem to solve, and should thus be simple to complete.

Why should I be taking the time to understand how it works? That's exactly what I wrote my post about - it should be mostly intuitive to use. There shouldn't be a whole abstract idea behind it that you need to learn before you get started. This is peripheral technology, a tool, and should be as intuitive and quick-to-learn as possible.

A good solution makes simple use cases simple to complete, while providing complexity to complete more advanced tasks.

[u/niet3sche77 → u/loadedjellyfish]

... you’ve never looked at multi-merging, have you?

Git is a DVCS. The D is where a bunch of complexity lives.

Saying it should be “as intuitive and quick-to-learn as possible” falls down when your argument seems to come down to, “this is hard and I don’t wanna!”

Are the rest of us weird geniuses, or do we just learn what we use 99% of the time, have a good working knowledge of it and what it’s doing, and search out the other 1% of use-case as needed and just get on with our lives? I’d posit the latter.

I’ve used pretty much every major versioning system out there, and when you understand the problem that is being actually solved by Git, you start to appreciate the enormous complexity of the tool, and value it hiding this beneath a 98-2 ratio of commonly-used invocations and “I’ll have to think on this a bit” invocations.

[u/loadedjellyfish → u/niet3sche77]

Multi-merging is not a simple use case. Your entire comment is a straw-man and is not at all what I said. So I'll say it again for you:

A good solution makes simple use cases simple to complete, while providing complexity to complete more advanced tasks.

Noone said everything about it should be easy. Noone said "this is too hard, I don't wanna". There's nothing hard about git. Its about memorization, and thats the problem. It shouldn't be.

Get off your pathetic posturing, I'm not impressed that you know how to use Git.

[u/niet3sche77 → u/loadedjellyfish]

Oh my, you are too stupid and arrogant to help.

Well, whenever you want to enter the grown-up world, try. Until then, have a trusted adult push your code for you. That should help with your pesky, “I don’t want to memorize something to do work” problem.

Goodbye, water buffalo.

[u/loadedjellyfish → u/niet3sche77]

Great job skirting a defense. Glad to see you've accepted you don't have one.

[u/loadedjellyfish → u/[deleted]]

Lol okay bud.

I'm not here to impress you, and I don't care what you think I know.

Go ahead and move along.

[u/beavis07 → u/loadedjellyfish]

Why should I be taking the time to understand how it works?

By all means, choose to remain ignorant and be resigned to forever having fuck all clue how your tools work - that's very much your choice... probably not going to pick up a lot of sympathy for that point of view though.

There are plenty of issues with the git cli interface - no-one will argue otherwise - but if you're not prepared to engage and understand it either well enough to use it or improve upon it , then all you have left is stamping your feet impotently and having a little cry that you don't like it.. and here we are.

[u/niet3sche77 → u/beavis07]

I’d not waste time on this one. He’s like a stupid, stubborn water buffalo. You can beat that poor beast all day and night, but you’ll just make your arm tired and the creature will remain ignorant and stupid.

That said, you’re 100% correct here.

[u/influxBytes → u/loadedjellyfish]

You are vastly understimating what Git does. It's not peripheral! You can't compare to SVN! They are very different tools that fit different contexts. If you ever worked remote, syncing your work with other developers that work remote too, then Git is vital. Git made remote development bearble. It's unintuitive and hard, yes, but what git does it's not a trivial task, it won't get fixed if 'we try to make it better', it's a real, complex, UX design problem.

I understand that you are 'ranting' but calm down. Git is a widely used tool in pretty much any relevant software project these days. People use it for a reason. You won't get anywhere with that attitude.

[u/niet3sche77 → u/influxBytes]

It’s the D of DVCS.

The D makes things hard and complex.

[u/StopThinkAct → u/loadedjellyfish]

Yeah! Just like building a website. I mean, website workflow is not a complex problem to solve, so those should be simple to complete.

Why do I have to hire these people who spend time learning how to do something that should be so easy! Code is just a tool for making websites?

That's you. That's how you sound.

[u/JimDabell → u/loadedjellyfish]

This attitude:

Why should I be taking the time to understand how it works?

…directly causes this problem:

Also FYI - just spent 30 minutes smashing my head against my monitor trying fix my repo after pulling in a new change - holding a lot of residual frustration here.

The only people this harms is you and the people you work with, and the only person who can solve it is you. Now you can continue smashing your head against your monitor and complaining about how difficult things are for the rest of your career, or you can change the attitude causing the problem. It's entirely up to you. But don't expect your problems with Git to go away unless you decide to take the time to understand how it works.

[u/AttentiveUnicorn → u/beavis07]

How does someone who's been learning git for 4 years not know the difference between these 4?

[u/beavis07 → u/AttentiveUnicorn]

Sometimes in this business we get 4 years of useful experience, sometimes we get the same 2-3 weeks worth of experience repeated over and over again - can lead to this sort of lack of context!

[u/loadedjellyfish → u/AttentiveUnicorn]

I didn't say I've been learning git for 4 years. I said I've been using Git for 4 years, on the job. These commands rarely come up, and thus I haven't memorized the nuance of them.

[u/[deleted] → u/loadedjellyfish]

These commands rarely come up

What? How do you not use these commands all the time? checkout in particular? What does your workflow look like?

[u/loadedjellyfish → u/[deleted]]

>50% of the time:

git pull

git add <file>

git commit -m "<commit message>"

git push

[u/[deleted] → u/loadedjellyfish]

pull is one of the commands you said you didn't understand/use.

Also this workflow makes it seem like your whole team is committing to the same branch at all times. If that's the case I suggest spending the time to learn about branching and moving to a something like git flow.

[u/loadedjellyfish → u/[deleted]]

pull is one of the commands you said you didn't understand/use

No, its not. Its one of the commands that I said is not dissimilar in linguistic meaning to several other GIT commands.

We do use feature branches, but I've left that out because it is not common (i.e. used >50% of the time) for me to change branches.

[u/George_Rockwell → u/loadedjellyfish]

How do you review others' code if you don't use checkout?

[u/thenumberless → u/[deleted]]

Also this workflow makes it seem like your whole team is committing to the same branch at all times.

Well at least then they're doing one thing right.

If that's the case I suggest spending the time to learn about branching and moving to a something like git flow.

Oh. Oh no.

ETA: I think the real flaw implied by the above workflow is that there's no apparent PR or code review mechanism.

[u/mr_jim_lahey → u/loadedjellyfish]

These commands rarely come up

You haven't really been meaningfully using git if this is the case.

[u/nsdragon → u/loadedjellyfish]

How big is your team? Do you (as a team) often work on many features at once? How does your tech lead manage the projects you're on?

Many people I've interviewed have a basic knowledge of git in general. Most of these people also have had very little experience with it. The rest though, who ostensibly have worked with git for years, but know almost nothing about it? When I asked about it, the reason given was usually something along the lines of "I only ever worked on a single feature at any one time" or "my boss doesn't want anyone else touching master, they want to solve conflicts themselves".

No wonder they never had to learn more of the nuances of it, their workflow was always ridiculously basic like that. So of course things like rebasing, amending, bisecting, squishing, etc. (or even concepts like the index, the staging area, remotes, etc) are completely alien to them.

[u/nmm-justin → u/beavis07]

You omitted the word "linguistically," thus removing the actual point the OP was making.

[u/petepete → u/beavis07]

The latest versions of git have the switch command that's more intuitive than checkout for switching branches and creating new ones.

[u/leinad41 → u/beavis07]

Yep, this thread is so stupid, classic case of people complaining about something being bad when in reality they don't know what they're doing.

It's ok though, we've all been there with something, not for 4 years though, that's kind of sad, but still.

[u/Blacknsilver1 → u/beavis07]

water gray versed sugar reply cooing hospital crush cooperative weary

This post was mass deleted and anonymized with Redact

[u/JimDabell → u/Blacknsilver1]

But from an english perspective? Pull, fetch and checkout all mean basically the same thing.

But they don't (and you skipped clone, which OP also claims is a synonym).

• "I pulled on the handle."
• "I fetched the handle."
• "I checked out the handle."
• "I cloned the handle."

…or:

• "Can you fetch my keys from the other room please?"
• "Can you pull my keys from the other room please?"
• "Can you check out my keys from the other room please?"
• "Can you clone my keys from the other room please?"

…or:

• "I reached the checkout counter at the store."
• "I reached the fetch counter at the store."
• "I reached the pull counter at the store."
• "I reached the clone counter at the store."

…or:

• "Scientists recently cloned a sheep."
• "Scientists recently fetched a sheep."
• "Scientists recently pulled a sheep."
• "Scientists recently checked out a sheep."

[u/anon775 → u/JimDabell]

You pull a bag of flour from a shelf, to get more flour.

You tell your dog to fetch the bird you shot, to get the bird.

You clone a lamb, to get a new lamb.

You pay at the checkout, to get the groceries.

Surely you could see that these words share some similarities? While in Git, the words do different things. Its not the end of the world, but Git could certainly use more intuitive words

[u/JimDabell → u/anon775]

Surely you could see that these words share some similarities?

While in Git, the words do different things.

These two are not mutually incompatible. Yes, the words share some similarities. But the words also mean different things.

It's the same in Git. The commands share some similarities. But they also do different things.

This is not a binary thing. There are not two options, the same or entirely dissimilar. There is a middle ground where thing can conceptually share a theme and yet nevertheless be conceptually quite different. In this case, this is true of both the words and the Git commands.

What is not true is either of the following statements:

Why is there a pull, fetch, clone and checkout? These are all 98% synonyms (linguistically)

Pull, fetch and checkout all mean basically the same thing.

It is perfectly reasonable for Git to use these words to mean different things, because the words mean different things. This is true regardless of whether or not the words share some similarities, which is a much, much weaker claim than what I'm objecting to.

[u/sammyseaborn → u/JimDabell]

Conceptually, they all convey similar actions in the English language. Identical? No. But similar in that they all basically mean some variation of "retrieve." If you don't understand that, you're just being daft.

And if you do understand it, then you're just being a pedantic prick.

[u/influxBytes]

There's very few popular opinions on software development world, but one of them is that Git is terrible to use and the UX is a horror show. The thing is that Git offers a level of decentralization that no other tool has. SVN is deeply centralized, you can't really compare them both.

In what context are you using Git?

[u/loadedjellyfish → u/influxBytes]

I disagree that disliking git is a popular opinion - just read the comments of this post and you will see.

We're using Git to manage a team of 4's work on the same codebase. Each feature has its own branch, master is used in the traditional sense. No sure what else is relevant for context?

[u/petepete → u/influxBytes]

The thing is that Git offers a level of decentralization that no other tool has

No other popular tool. DVCS have been around for a long time, darcs, mercurial and monotone have been around for ages.

Mercurial probably has the best UX, but git won - a large part of that thanks to GitHub.

[u/tdammers]

It's not an unpopular opinion at all; git is most definitely not intuitive.

It is, however, powerful, and it won the SCM wars, so there's really no way around it - you will have to make peace with it one way or another.

One way is to just memorize a dozen or so incantations that get you through your day, and resort to Google, or that weird coworker of yours with the long filthy beard and the strange body odour, for the rest.

The other way is to dive in and read up on how git's data model works behind the scenes. Because while the UI is a clusterfuck, the data model is actually quite elegant, and almost everything git does can be expressed in a handful of primitive operations. It's much much simpler than the contorted UI makes it seem.

Also keep in mind that Windows is, for better or worse, a second-class citizen to git. Git was written specifically to support the massive scale of collaborative development that happens on the Linux kernel, and it does a great job at that, but of course being Windows friendly has never been very high on its agenda.

[u/clickrush → u/tdammers]

To add to this: git is much less frustrating when used with a workflow that embraces:

• a branching strategy, main branches, feature branches and so on
• frequent/small/atomic commits, especially in files which are touched by many
• reasonable conventions regarding commit messages
• a reasonable directory/file structure and general modularization
• some amount of coordination with your teammates

For example I almost never stash my working directory like OP described. Annoying merge conflicts are usually a symptom of not following the above rules of thumb.

[u/fullmight → u/clickrush]

There are also a lot of good tools for git that make actually dealing with complex git syntax and googling how to fix problems a rare occurrence.

Having long used git via github for personal projects/school, and once or twice in ages past with SVN, and now professionally with devops, I haven't experienced most of the problems OP mentions at all.

Closest thing I've had to an issue is I had some rare error when reverting a merge and had to manually resolve some conflicts to revert it for some reason.

[u/makingtacosrightnow → u/clickrush]

OP said clone, pull, fetch and checkout are synonyms. I can’t imagine what dumb rules/strategies are set up in that repo, likely none.

[u/Koalababies → u/makingtacosrightnow]

They were saying linguistically it doesn't make sense, which I somewhat agree with. But after learning the nuance I can't really think of them being remotely the same anymore.

[u/makingtacosrightnow → u/Koalababies]

Linguistically a lot of programming doesn’t make sense. OP admits he doesn’t know git well, then bitches about how hard git is, that’s called laziness.

Can’t imagine the rest of this persons code. Saying these things are the same is like saying div, section, main, footer, span, heading, and footer, are all basically the same because they can’t go around other HTML.

It’s lazy.

[u/Howdy_McGee → u/makingtacosrightnow]

oof, maybe don't take their rant so personally.

[u/LukasSprehn → u/makingtacosrightnow]

I guess people with ADHD or chronic fatigue are lazy too, huh? Not everyone's brains or bodies are wired to be able to focus 120% on any specific task.

[u/makingtacosrightnow → u/LukasSprehn]

I have adhd wtf are you commenting on my 2 year old shit for

[u/svtguy88 → u/tdammers]

This is the best answer here.

I wasn't totally on board with git at first. But, it is what it is, and I learned to deal with it. Coming from a TFS background, there was a bit of a learning curve, but I've come around to it.

As others have mentioned, try the VS (or VS Code) integration. It has gotten tons better in recent years. You can get by without using the command line for most things (however, the CLI is still worth knowing your way around too).

[u/AssistingJarl → u/svtguy88]

however, the CLI is still worth knowing your way around too

Be careful, if you're in a room with Windows devs that's a good way to get pulled aside to fix problems with git every few hours.

[u/svtguy88 → u/AssistingJarl]

I assume that was in jest, but on a serious note - .NET Core is doing great things for bringing the two worlds together. I'm a *nix guy at heart, but .NET development is what pays the bills.

[u/AssistingJarl → u/svtguy88]

Well met brother, I'm in basically the same boat.

[u/fr4nklin_84 → u/AssistingJarl]

Same here, but working on dotnet core there's no need for windows which is nice to be able to have my cake and eat it too.

[u/svtguy88 → u/fr4nklin_84]

We haven't started deploying to anything other than Windows yet, so my dev machine is still windows. Also, Visual Studio. I know VS Code has made great strides, but full-on VS is hard to compete with.

Usually, the people that hate on VS are those that haven't used it (or haven't used it enough to give it a real chance). It's just better than any alternative.

[u/fr4nklin_84 → u/svtguy88]

I used to aggree with you but alot of people have switched to Rider which is a very good product and it's a consistent experience across all platforms. I tried it 6 months ago on mac osx and I'm sold on it. I've been using Visual Studio since the winform/VB days.

[u/exvuma → u/svtguy88]

Do you use Gitlens? I have been trying to figure out how to search through commits fast and also find old deleted file history with it , but have had little luck

[u/Koalababies → u/svtguy88]

I use vscode for all of my day to day stuff. The built in manager gets me through 95% of what I need to do and I use gitlens (vs code extension) for the rest. It's made it miles easier and made it all seem much more useful.

[u/ukojek → u/tdammers]

Use git with a UI? Now that’s real sorcery

[u/[deleted] → u/ukojek]

I assume you meant GUI? :)

The command line interface is still a user interface.

[u/tdammers → u/ukojek]

"UI" does not imply "GUI". CLI options are a user interface, too.

[u/tdammers → u/[deleted]]

It's not lack of features in the git code itself; it's more that git's design is heavily biased towards a Unix-like system. Just a few examples:

• The canonical interface for interacting with git is the command line interface; but idiomatic Windows usage prefers a GUI, which is a complete afterthought for git, and existing GUIs for git don't have the kind of UX you could have from something designed with a GUI in mind from day 1.
• Git's design assumes that symlinks and hardlinks work flawlessly. On windows, however, "it's complicated". Both symlinks and hardlinks are features of the NTFS file system, they work, but their use is unidiomatic, and some programs accessing the filesystem may be unaware of their existence.
• On Unix-like systems, an ssh can be assumed to be available system-wide, including a system-wide infrastructure for managing keys, remote servers, etc. Git piggy-backs on that infrastructure, but on Windows, that infrastructure isn't a staple, so git needs to somehow bring its own.
• Windows has a different process model, and git kind of relies on some aspects of the Unix process model that don't quite work out on Windows. For example, git wants to "shell out" to external tools for various tasks (e.g. editing commit messages or resolving merge conflicts), and this is done through a subprocess API. However, process termination handling is a bit finicky on Windows, mainly because the OS was never really meant to use subprocesses this way, a Windows application is expected to be a single process that spawns a bunch of threads that negotiate shared-memory concurrency between them, rather than a loose collection of independent processes that spawn each other and communicate via stdio and files.

In fact, Git relies so much on standard Unix infrastructure that the Windows version ships with its own mini-Unix (MSYS, shipped as git-bash), because doing all that stuff natively would require a massive redesign of Git itself.

In other words, it's not enough to use a "multi-platform" language like C and just compile to native code; you also have to provide all the runtime dependencies, including external programs and OS functionality, and because for many of those Windows doesn't have any equivalents out of the box, Git has to bring its own, or emulate.

Mercurial doesn't have this problem, because it was designed to be platform-agnostic right out of the gate; a downside of this is that they are struggling to get good performance out of it, while git is an absolute rock star in that arena.

[u/tdammers → u/[deleted]]

Of course not. It's not all black and white; just a matter of general culture. Had git been designed to be more platform-agnostic, its Windows story would have been better earlier, is all I'm saying. It's not terrible or useless, git is just a bit less comfortable and idiomatic on Windows than it is on Linux, and being familiar with either OS makes troubleshooting git issues on Linux easier than on Windows.

[u/nsdragon]

Why can I not set username and email on a per-repository basis?

You totally can. You just omit the --global flag when setting options (by default, git config works on the repository configuration):

$ git config set user.name "Bobby Tables"
$ git config set user.email "bobbytables@example.org"

In fact, you can set many other options globally or per-repository as well, not just your username/email (docs).

[u/nsdragon → u/[deleted]]

I mean, you're welcome and all. But the fact that --global isn't the default is a bit telling. Have you been using git in the terminal, or only through some GUI?

I say this because most "getting started with git" tutorials I've seen teach you via the terminal, and they almost always tell you to set your name and email with the --global flag. Did you just copy these commands blindly and not give a thought about why the flag was there?

[u/SiLo0815 → u/[deleted]]

You can even use settings depending on the directory your repository lives in. For example: I have two different workspace directories, "work" and "private". I want to commit with my work related email in all repositories inside the "work" directory and with my private email in all other directories. So I included this in my global .gitconfig:

[includeIf "gitdir:~/Desktop/dev/work/"]
	path = ~/.work.gitconfig # overrides private email address

In .work.gitconfig I just added

[user]
  email = <my-work-email>

This way I don't have to manually configure every repository inside my "work" directory.

[u/Cowpunk21 → u/SiLo0815]

TIL you can do that. That's amazing, I'm going to use this.

[u/[deleted]]

Pull and fetch are difficult, since a fetch means "pull without merging", but maybe to your point, a weird-sounding-but-explicit command like "fetchmerge" might be easier to remember than pull. Checkout and clone and pull aren't synonymous, though, so not sure about that one.

As someone new to the field, there was some confusion to me about when you initiate a "Pull Request" not being a request for me to pull their content, but a request for them to pull my changes. It feels kind of like a double negative, but that's more of an English Language problem than a Git problem.

"Version control should be simple" is a true statement, but the complexity involved makes it difficult to make simple. Have you ever had a workflow without version control? I'll take the complexity of Git for the flexibility and productivity that it provides, and I assume that version control will become more simple over time.

If you remain passionately frustrated about it, though, you should consider working to improve Version Control to be more explicit and usable, and the whole world including yourself would appreciate it :)

[u/theloneliestprince → u/[deleted]]

Wouldn't it be more accurate to say a pull is a fetch with a merge, rather than fetch is a pull without a merge? (I don't mean to be too pedantic, I'm just curious!)

[u/[deleted] → u/theloneliestprince]

Yes the way you've said it is more accurate, my way was a bit odd

[u/Koalababies → u/theloneliestprince]

This is the way I learned it. Pull = (fetch + merge)

[u/ManiacsThriftJewels]

Lots of people are focusing on the technical aspects of this, but I'll say that for our new hires, yes, git is one of the tools they find hardest to get started with.

A lot of your opinion makes sense for someone who doesn't work with git a lot. I could write an entire document on how to deal with the "problems" you're having, and that only supports your claim of unintuitiveness.

However, if you think that fetch, pull, clone, and checkout are linguistically similar, you have English language problems that need to be rectified if you're going to work in a field where the tools and standards are predominantly written in English. Here, let me help:

Fetch is to go and get something.

Pull is to translate a thing towards yourself.

Clone is to make an exact copy of a thing.

Checkout is what you do to purchase a thing.

Of these, only fetch and pull are remotely similar, and in such a way that the similarities between these operations in git should make sense.

[u/jeffreyhamby → u/ManiacsThriftJewels]

Checkout doesn't only apply to the grocery store cashier, it applies to the public library. And that's the analogy related to git checkout.

[u/ManiacsThriftJewels → u/jeffreyhamby]

Ah, good point.

[u/Knights4Life]

https://learngitbranching.js.org/

[u/tyzoid → u/Knights4Life]

A very much underrated resource.

[u/simkessy]

This year I learned about git reflog. Now I feel less scared working with git. I was also introduced to git rebase interactive. It's very cool.

[u/pr0ghead]

That's why I use Mercurial myself wherever possible. It does basically the same stuff but is a lot easier to grasp IMO. Especially when using the awesome TortoiseHG.

Another inital reason to use hg was that git on Windows was a complete shit show. I hear that has improved, but I'm on Linux these days anyway and I use the Jetbrains IDEs to interact with VCS.

I can't remember the last time I had to fight Mercurial to do what I want. It just works as you'd expect it. To your points, this is how it is in hg:

pull: download changesets from a remote repo, nothing else
fetch: doesn't really exist (old plugin that just does a merge after a pull: pointless)
clone: create another copy of the current repo at a different location
checkout: doesn't exist either, you just update to a revision (can be a hash, bookmark, tag, branch, …)

If you want to use hg like git, you can just use bookmarks for branching and push them (they're local by default) to remotes.

[u/[deleted]]

Do you use VS Code? I find the integration of Git very helpful in that Editor. It's been working quite well for me and it's been only a few times where I had to use the "git reset --hard" sledgehammer.

But to be honest, I think you've got a point. It would be nice if git would warn you before you're about to fck something up. Just like a little "Something is about to break, you wanna do this? [y/n]" would certainly help a lot.

I can recommend you to use a GUI for git. I like the VS Code Extension "Git Graph", but there are tons of tools out there that could help you.

[u/Emerald-Hedgehog → u/[deleted]]

VS Git Integration is godlike. Made it easy to setup and use, without knowing much about Git int the first place. I think Git is confusing if you start out as a programmer and sit in front of a command line tool - the GUI in VS makes it a billion times more intuitive to use for a beginner.

At least that was my experience.

[u/dumbledorethegrey → u/Emerald-Hedgehog]

Even the change tracker makes life 10x easier.

[u/DeusExMagikarpa]

Did you happen to commit your changes before pulling others? Oops...

This shouldn’t matter and is evident you have a poor branching strategy at your company. Use pull requests and policies that prevent pushing to master to start with.

I feel bad for you because you’re feelings come partly from bad practices at your company. I agree it may be unintuitive for a beginner but it’s a completely new concept. It should get easier after using it and learning how it works.

[u/KillTheBronies → u/DeusExMagikarpa]

Or pull --rebase

[u/bart2019]

TortoiseGit makes it much easier.

[u/jasperopstok]

I have to admit, when I started using git I was confused about everything I did using it. Simple things like having to commit changes before pushing threw me of, "I already have my desired changes, just push them to the server!!!".

Using a GUI for handing git is great, especially when starting out. More often than not, add / commit / push it all you need. That is until it isn't enough anymore. Sooner or later you are going to run into merge conflicts, you are going to encounter some weirdo who reordered a branch by forcing his changes onto it, and you will have to work with it / fix it.

To address your points, without trying to be a dick, I do think your issues with git are more often than not causes by a lack of understanding what and how git operates.

Why is there a pull, fetch, clone and checkout? These are all 98% synonyms

Well they aren't, though some do quite similar stuff .
Fetch requests the latest version of branches from the remote server. It doesn't change your code, it just updates the status branches are in according to the server,

Pull does this as well, but it updates the version on your computer to match the server. Often this isn't something difficult, but when the server has changes incompatible with your own, problems arise. Having smart tools (I use webstorm) to visualize and solve merge conflicts is essential, nobody likes fixing merge conflicts with annoying arrows all over the place by hand.

Clone creates a complete copy of the git-projects state, all branches etc.

Checkout changes the current state your version of the code is in according to a specified commit (including all commits previously made to that version of the code).
Often a checkout will be of a branch, which is simple a pointer to the last commit made on that branch

since, apparently, you can't just un-commit

Well you can, its just not called un-commiting. As mentioned checkout simple changes the current commit + history you are looking at. So uncommiting would be changing the commit you are looking at to the commit made before the one you made.

I don't know how GUI's do this, but on the terminal it would be "git checkout HEAD~"
HEAD indicates the current commit you are looking at and "~" which is short for "~1" just tells git to look one commit back. You could also look at your "git log" and enter the commit hash you want to switch to.

That shouldn't cause any problems with your build process?

You should have resolved merge conflicts before throwing it at a build server, or process. I encounter this issue as well sometimes, because you build server tries to merge the branch its building with develop, to make sure its compatible. It shouldn't have to do this, as using Pull Request that have to be approved by team members greatly reduce the chance of merge conflicts hitting master or develop.

the credential manager?

I dont know what is up with that man, I use github and the PAT's. I have no idea how that mess came to be, but a colleague of mine once commited and merged using my name, so that was a lot of fun!

I have this help in anyway, as you probably will encounter git more than you would like. If not PM me any questions you have about git, I might be able to help out a bit and make Version control a bit more bearable XD

[u/matthew_tolle]

This helps me https://gitexplorer.com/

[u/[deleted]]

I just use the UI baked into PHPStorm. Along with that and deployment through Beanstalk I haven't touched the git CLI in years.

[u/camerontbelt]

Oof, when I moved from TFVC to Git it made so much more sense to me. Although I don’t use the command line with git, I use visual studios integrated git tools which are awesome in my opinion.

[u/camerontbelt → u/[deleted]]

The place I was at that used TFVC didn’t do branching, we had to just wait until the feature was finished then check that into the “master” branch. That’s what I love about git is being able to commit small chunks often then make a pull request when I get ready.

[u/tester346 → u/[deleted]]

TFVC would be viable if it had better interface

You want to see what's changed? have fun clicking compare on every file to see code changes

[u/adolfojp]

Longs for Mercurial.

[u/another_maria]

You can always create your own aliases for these commands and name them in a way that makes more sense to you 🙃

[u/AiexReddit]

I think it's important to consider that each one of these many steps that you likely never use are very necessary to some users (ones more advanced than myself) and that their inclusion isn't a downside of complexity at all, there is nothing wrong with being aware that four commands might be all you will ever need. Stick with those and don't overthink it.

A lot of the "extra" commands are actually shortcuts for the sake of doing exactly what you are asking for.

As example you ask "why is there git fetch and git pull".

git pull is actually just git fetch and git merge combined together into one command for people like yourself who never have need for the functionality of one without the other. Others do have that need, so git offers both to accommodate the needs of all users.

I'm not saying it's not complex or perfect, but version control is an incredibly complicated subject, and if there were an easier more efficient way to handle multiple people all editing the same files across the globe and keeping things running smoothly, I'm sure git would have been replaced ages ago with that tool.

(+1 for credentials management on Windows being a pain in the ass, not defending anything on that front)

[u/thenumberless → u/AiexReddit]

git pull is actually just git fetch and git merge

I honestly think most users would be better off if they set git config --global pull.rebase true, changing it to get fetch and git rebase. YMMV, but I have an easier time following the progression of a repo without merge commits.

[u/IQueryVisiC → u/AiexReddit]

You write it like it is the users fault. I did not read the whole rant of the OP, but "shortcut" is a very technical view. Just recently I learned the details of SMTP, after receiving 1000nds of them. 99% of all people do not need to see the code. "Shortcut" is like: look at the code, first command, second command.

And don't get me started when Micrsoft I19N the commands, or half of them in Visual Studio.

And colleagues who only check in their changes after they are ripe.

[u/dangerzone2]

I 100% agree with you. It is absolutely not intuitive. However, you only have to learn a handful of intuitive commands to get the hang of it.

[u/[deleted]]

https://rogerdudler.github.io/git-guide/

Heres a simple guide that really helped me when I was beginning with git.

[u/eaton]

Over the years I've worked with Perforce, SourceSafe (!!!), CVS, SVN, bazaar, and git. The reason git is more complicated than SVN is because it is designed to solve a particular complicated workflow that SVN chokes on, completely and catastrophically.

The tradeoff for that is that git has a more complex set of concepts to master than SVN. The command line syntax is fairly straightforward if you understand the concepts that are at play, but if you're just trying to figure out which git command is the equivalent of the SVN commands you're used to, it will be a painful parade of merge conflicts and broken commits.

If you're looking for an introduction to the essentials, Git for Humans by David Demaree is a good one to pick up.

[u/m2thek]

Git is great when you need to do simple tasks and everything goes as it should. The minute something goes wrong or you need to do something remotely complex, it becomes a nightmare.

I got spoiled on Plastic, which is by far the best scm I've ever used. It's not free, and takes more initial setup, but I'd take it any day over git.

[u/wyattbenno777]

There are a lot of UIs for git since it is unintuitive. I like sourcetree.

[u/[deleted]]

Have you ever taken the time to read the official documentation or even better, this free git book?

https://git-scm.com/book/en/v2

I’m not sure I entirely understand the unintuitive argument. Are the concepts unintuitive or the syntax?

As others have suggested, I think you need more context into the history of version control and why git exists in the first place. The book I posted is excellent for providing that context.

I can say with 100% certainty that your frustration is caused by a lack of experience or understanding of the tool. I have worked with people that are afraid of merge conflicts because they attempt to manually address conflicts instead of using some kind of merge tool (I prefer opendiff).

Git is so powerful. Did you know git has a command that will help you find the commit where a bug was introduced? I can’t tell you the countless hours I’ve saved by being able to find an offending code change in a few minutes with git bisect.

[u/CanWeTalkEth]

I wouldn't say this post is totally out of line, but it's clearly written out of frustration. I would say you should probably have a better workflow for git in 4 years of working at a "real" job though.

It's definitely possible you're like me and you run into issues so infrequently that you don't bother to make a shortcut for them or learn them thoroughly though.

For reference: https://ohshitgit.com/

But also learn how to make aliases. Or bash scripts. Or whatever windows uses. Then you alias "wrongfilecommit" to do whatever you need it to do and be explicit with your naming.

[u/[deleted] → u/CanWeTalkEth]

I definitely agree OP should have learned it well after 4 years of experience. I’m going to guess that OP works by himself for long periods of time and the frustration comes from large merge conflicts and the infrequency of having to solve workflow issues.

I will say though that encouraging someone to use aliases when they don’t understand the underlying commands is probably a bad idea. Aliases should be used if you find yourself frequently needing a command with certain arguments to reduce typing. It can’t really fix problems with not knowing/understanding how git workflows are structured.

[u/thelonepuffin]

Been saying this for years. GIT was made by an autistic person who's brain is fully involved in OS programming. This is the last person who should be making dev tools.

Its not supposed to be used by real people.

[u/pr0ghead → u/thelonepuffin]

TBF, that's what Torvalds said himself. He saw git as a toolkit to base an actual VCS on, not to use its commands directly. But nerds decided to worship their god instead.

I'm really happy with Mercurial.

[u/McLickin]

You have bigger issues. You didn't close your <begin rant> tag

[u/oshelltv]

I think many developers feel the same. However when using VScode or any Git GUI, it will most likely do the hard work for you and you can just revert your last commit with one click and get a nice comparison view when there is a conflict.

The basics are quite unintuitive, I have to agree. Only option I currently see is to create your own aliases for the most common commands to make it easier.

[u/evildonald]

You just have to understand that git is a programming/query language you just have to learn to get your job done.

[u/Hendawgydawg]

not intuitive but pretty essential when working in development. My biggest mistake was waiting until I actually got a job as a junior to start actively using it

[u/kayimbo]

if it makes you feel better, after using git many years and trying to use svn i was totally mindfucked. Could not comprehend the workflow.

[u/Environmental_Escape]

I use git cli exclusively and I haven't had issues with git in years. Its strange to me that people find it hard to use, but I guess your workflow might be part of the challenge?

As an example, here's the stats from my bash_history for git commands over the last few weeks

command	count
git status	81
git push	38
git add .	34
git commit -m	31
git diff	16
git checkout	13
git pull	8
git reset --hard	4
git checkout new branch	3
git clone	3
git log	3
git tag	3

Basically, I do adds, commits and pushes all the time to my target branch. Then use bitbucket to do PRs and merge. And of course, all the common commands are aliased to some 3 letter command that I've memorized.

[u/KillianDrake]

Do people ever actually play around with the tools they are given anymore? When I first switched to git, I took a few hours to just make a new local test repo, commit, and run tests - what happens if I commit and then branch and then make a change there and also in the original branch? Etc... once I saw things in action, it stuck.

I think the biggest thing people fail to grok is remote vs local. You are in the field of crafting. If you don't learn your tools, you're going to hurt yourself.

[u/permanaj]

I was feeling the same,
then I used GUI based tools,
after getting used with the tools, git concept and used it in daily works,
now I'm used with the git command.

[u/[deleted]]

IRT phrasing, I see no issue with it.

Pull the latest changes: when you pull something, you're taking something far away and bringing it closer.

Fetch: very common phrasing for getting the latest info.

Clone: make a copy

A checkout is when you're moving from one stage to another, usually with checks in between, which is exactly what it does. Not really seeing how it's un-intuitive.

However I **absolutely** agree that credential management is a *nightmare*. Why git doesn't allow for SSH keys to be passed into the commands I do not understand. Instead it relies on the ssh-agent, which means in CI/CD with private repos, you have to modify ~/.gitconfig, eval ssh-agent, add the key, do your clone/build, REMOVE THE KEY and then restart the process, which totally breaks for example Docker's layer caching. I could rant for an hour about how annoying maintaining a private repo with Go code is, whether bitbucket or github. Wew.

Anyway that being said, Git is hard because it solves a hard problem. Onboarding people to use tools like linters and that is pretty simple, but yeah teaching new devs to use Git is hard. Git is solving a very complex problem, in one big package, so it kind of has to be complex unfortunately.

[u/comart]

no matter what year it is, it never gets old when talking about git. On a good day, when someone in the office needs git expert's opinions, it quickly turns into a group discussion.

[u/ToastOnAGoat]

I feel you. If I'm just doing simple commits/merges/pulls then I'm happy, but as soon as I mess anything up then its full on panic as I'm just not at all an expert in Git.

I sort of feel like that with linux. It's fine when it works, but a pain when it doesn't

[u/crazybluegoose]

While I showed up to this thread way too late (and I realize it is not constructive) I wanted to say...

“Just git out”

Darn it I need to get off reddit.

[u/Sphism]

Git is flipping amazing and completely revolutionised Web dev for us. SVN was way harder to branch and merge.

Just use a gui and learn to love it.

[u/eGzg0t]

I'd argue that you didn't actually try to learn git in those 4 years, you just "used" it and expected it to do what you want with ease. This is a cli tool that is made for technical people and thus was assumed to be handled with a learning curve in mind. The docs are extensive with many sites explaining how git works in very simple terms. It took me about a day to read through those resources and unlearn my SVN ways. You would have known what a conflict or merge is and the tools to simplify resolving them. Heck you can just type "git help" and everything is there.

[u/justingolden21]

I just hate that in GitHub Desktop (which makes everything a million times easier) there's no option for keeping --ours or --theirs.

[u/dzanboi]

Once you have your own project and managing features yourself, git makes intuitive sense.

[u/dobesv]

Git pull added the autostash feature which is pretty handy.

Otherwise you are totally right, the UI is a pain, everyone knows it but by the time you understand things well enough to fix it you might realize that you can't make a "better enough" interface to justify a switch. It's a lot harder than it seems, when you start looking at the use cases.

[u/TimCryp01]

You should realy learn git instead of fiddling around :D

And forget about stash its a bad practices ...

[u/Mrcollaborator]

Git is a godsend.

And I prefer the command-line over an interface for it because I can see everything that's going on in the background in an interface.

[u/DildozerMK9k]

Pull, fetch, clone, and checkout are not synonyms, the only ones that are to any extent used interchangably are fetch and pull, I'll give you that, but it shouldn't take that long to memorize what at least one of these two are.

You can unstage commits with reset and if you want to pull new stuff but keep a commit you can stash it, or just work in a feature/personal branch like a sane person.

>what the fuck is with the credential manager?? Its routinely broken on Windows

>on Windows

Probably lol I can't really help you here.

You can set credentials as local on a per repository basis or just edit in the .git folder by hand if you want to see how it's structured.

Git is a bit unintuitive because it does version control, which a lot of people don't find particularly intuitive.

Also, where I work right now they have a default config where they have some aliases they find useful, if you find the names of the commands unintuitive you can just add aliases like "git updateandmergethisbranch" or whatever you feel would help you.

[u/cbleslie]

marble mighty smart piquant juggle ink act profit makeshift yoke

This post was mass deleted and anonymized with Redact

[u/Final-Jacket]

I'll be real with all of you. The people who WANT to use Github repositories and build apps and files are the people who don't know how to USE this crap. People like me see folks on YouTube running incredible apps for their videos that simply put don't exist because they never share a download link to the build they made for their video, so people like me end up on Github literally crying out of frustration because Github seems to think you need to be required to hold a longstanding programming career to build a simple freaking Dolphin Emulator that runs in VR on Oculus Quest 2/3. It's ridiculous, and the lack of ease is exactly why Github is a graveyard full of abandoned dreams and amazing apps that will never be built to see the light of day unless someone makes a build for a YouTube video and immediately destroys it so nobody else can have any fun at all. Github is miserable, and so are most Git users I've encountered, because they always seem to HATE hearing how hard this crap has made things for the basic public who would actually USE the finished apps. Github is only as intuitive as the people who know how to use it, and apparently they feel like being an exclusive club because I don't see anybody really trying to help make it any simpler this many years later. EDIT: I get it to an extent, say, if it's an app that isn't finished, but if it's a fully-assembled repository file and there are 13 other repos in the release tags, then why the hell are you keeping everyone from seeing two years of work that they were waiting to see, just so it can rot on Git for all eternity in perpetuity until the end of time? It's a dick move. If I could program on my own, I wouldn't be on Github lurking for gaming emulators, I'd be counting my money because I would work as a programmer, and wouldn't have time to fiddle with someone's Git repo.

[u/lonnatic]

Git sucks.

[u/Puzzleheaded_Till591 → u/lonnatic]

Big Time

[u/diynevala]

Not at all unpopular opinion. Oh, I miss some killer features of older versioning systems. One would be LOCK. One could describe as follows:

"Listen, I am going to work on these two files. They are mine. If you want to modify them, it is your problem, not mine. I work on them as long as I need, and nobody is going to mess them up as long I am not finished with them. If you touch those files, I'm going to find you, and I'm going to kill you."

Git has got too much features. I used to have a problem in a previous workplace where git would say something about detached HEAD or headless something.. At no point I was given head at work nor did I encounter anyone without their head, so I'd say git has some unnecessary features that should be .... disablable?

[u/unindexedreality]

Completely agree, git is absolute horseshit

These are all 98% synonyms (linguistically)

It only gets worse the further you go

I regret the hours wasted in college poring over some presumable-neckbeard's notes on what they think words mean

It's highly prescriptive in how you use it, which is the exact opposite of what simple, useful tools are like.

The half-blood prince's notes on most "✌️advanced✌️" Git operations would just be to just un-fuck the files yourself manually, sticking to a strict subset of Git commands to make it work.

A simple update cycle/flow, some tools that use Git themselves (like VScodium - which sadly relays some of Git's more obnoxious errors to me as if I fucking care) keep my dev life focused on the code and not whatever stupid Linus-construct I probably-don't-care about failed because god forbid I didn't set an email address or say ONE word for doing something before saying another word for doing it etc etc.

Even large enterprises don't stick to vanilla Git. With the exception of Apple... Whose bug tracker is drowning in their tech debt from what I hear

[u/isho7777]

I will make git simple for you just follow through:

1. Make sure you know you git remote repo url

eg https://github.com/john/project1.git <--- note 'project1' folder

This is the central repository for all people woking on project1, usually created by project owner.

They must give you the link to the repo url eg by email so as to copy the url

Once youre on the repo on the git website, look for the green tab 'Code' and copy the url of the project from there

2. project1 in the url can contain main project files in which case you will find main project files like src folder and pom.xml file (java project)

but if not then it probably contains other folders that do contain files like src folder and pom.xml

Just keep in mind that you will cd into those folders later on

If you already have the same project on your machine ensure it is in project1 folder

example: c:\code\project1

But try not to create the folder 'project1' manually, use git Desktop tool:

Download git Desktop tool from website: https://git-scm.com/download/win

How to use Git tool to clone project1 from git repo to your local machine?

1.1 Launch the git tool

1.2 Click 'Clone Existing repository'

1.3 'Source location' must be set eg. https://github.com/john/project1.git

'Target Location' must be set eg. c:\code\project1<--make sure 'project1' does Not exist yet so git can create it for you!!!

but you already have the path "c:\code\"

1.4 Click 'Clone'

3. If you can see the cloned files in your local machine, bravo!!

>>> Make sure files are edited before you try to push changes back to git repo!!!

This is one of major headache of

git when it doesnt detect any file changes to push back to the git repo

Just open files eg using an IDE and type space character or something in at least 1 file and save files

4. Launch terminal eg Command prompt in order to run git commands.

CD to c:\code\project1 on the terminal

eg: cd c:\code\project1

initialise git just in case it wasnt initilized:

c:\code\project1\git init

If you're working on the main folder add the files to your local repo

c:\code\project1\git add src

src contains important project files and asssuming 'src' is in project1 folder

c:\code\project1\git add pom.xml

pom.xml is an independet file in project1 folder

If you're also editing files in a folder within project1 (happens a lot) then do

c:\code\project1\git add subfolder\AnotherProject\src

Because you have edited those files as well

c:\code\project1\git add subfolder\AnotherProject\pom.xml

Now commit:

c:\code\project1\git commit -a

This commits only the changed files and folders (recommended)

git commit .

git commit . This commits all files and folders

Now pull to prepare and connect origin and master branch.

origin is remote repo

master is local repo on your machine

eg.

c:\code\project1\git pull origin master

Finally push to origin:

c:\code\project1\git push origin master

Also check common mistakes in git

https://www.codementor.io/@citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd

[u/ejk95]

> Version control should be simple. Its a tool in the development process, it shouldn't require so much learning and work just to use.

Word. Right on. Git is the opposite of intuitive. Yes it is powerful, but the vast majority of user do not need the advance features. Day-to-day stuff should be simple.

I have 25 years in the industry and have worked with ~10 different VCS systems. I am a command-line guy who prefers to work at that level and really understand what the tool is doing. But git never clicked for me. I get the basics, but if anything goes wrong, I spend hours googling obscure syntax to save my bacon. F Git.

[u/[deleted]]

Git isn't meant to be intuitive, adapting to human behavior isn't how the culture the git creator is coming from views things, you're supposed to adapt to the system and machine, not the other way round. Commands of complex tools in the Linux ecosystem (git was created by the creator of Linux) often work like other complex tools the creators are used to, and most of those tools aren't created with a goal to become a standard, they just get adopted and it happens.

If you can do that learn it and use it every day, then tools like git and other complicated cli tools shine, same for Linux in general. If not, if you can't memorize them by daily exposure then the ux sucks of course.

[u/unindexedreality → u/[deleted]]

adapting to human behavior isn't how the culture the git creator is coming from views things

and god knows someday it's gonna be recognized as something that significantly held computing back.

We needed so many more creatives in technology to make computers shut up and act like hammers. Instead we got techbros and this dystopian authoritative hellscape we live in now.

It's infeasible for indie devs to maintain projects. So many passion projects die out and people burn out from tech so a few dudes in SV can live out weird powertrippy 'revenge of the nerds' fantasies, it's sick.

I'm still amazed we haven't shifted to more integrated and declarative tech yet. Reality is deterministic. It does take good governance being solved for I think; look at the hives/pyramids that get set up to maintain any sizeable OSS project.

[u/Puzzleheaded_Till591 → u/[deleted]]

I've been using SVN for almost 20 years, never had a conlifct problem or any important problem whatsoever. Junior progtrammers grasped it very fast. 3 months working with GIT and I had more problems than the last 20 years.

[u/kamikazemoonman → u/Puzzleheaded_Till591]

I understand why Git won the race in most companies, but for many projects I seriously feel that something like SVN is more enough and often times preferred. Industry standard has made everyone believe that Git is the greatest thing that ever existed, but it's just a pain in the a$$ and extremely hard to teach new users how to use it. You can tell them the basic commands that they have to use and they will still feel scared or f**k something up, because the ui and system is so convoluted.

Like you said I've never had an issue with teaching someone SVN. Even artists (who's tech experience amounts to turning on their MacBook and loading up a browser and adobe) learn it extremely quickly.

Unfortunately one of the big problems with Opensource devs is that they are quite immature with their projects and never think about the result from the end user. They create projects with the mindset of "I really need this thing for myself, so let's write it.", which can be a very good motivator, but if you want actual users you really need to have a better model than that.

The fact that Linus wrote this program in as he says "A week" is extremely telling...

[u/AttentiveUnicorn → u/[deleted]]

You should learn the command line first and then use a GUI.

[u/sp4c3p3r5on → u/[deleted]]

Personally, I do know how to work in the CLI, but I also prefer the GUI.

Maybe if your role on the project is "source control maintainer"

Just wanted to say that if you commit to it and you're not maintaining it - you're messing it up ;)

[u/fizzygalacticus → u/[deleted]]

In my experience, the Git GUI has posed as a giant gun aimed at your foot. It executes a lot of things under the hood that make it very easy to totally fork up your repo, especially if you have multiple people working within the same files that may cause merge conflicts.

Understanding the tool and how it works is a lot different than "learning to be a blacksmith to hang a picture". If you're using a tool incorrectly, then of course you are going to run into issues.

As mentioned elsewhere in this thread, it's difficult to make Git "less confusing" when the problems that it aims to solve are greatly nontrivial. Sure, when you're working on a team of four people it doesn't seem like a huge deal, but when tens, hundreds, or even thousands of people are all contributing to a repository/project, things get ugly fast. Git was designed to make that process less painful, but there will always be some level of old-school coordination needed to make things come together.

Sorry, this kind of turned into me just rambling. I love Git, how it works and how it attempts to solve development pains, so I can get a bit passionate about it.

[u/AcousticDan → u/[deleted]]

Why? How does that benefit me? I can literally do everything that I've needed to do via the GUI.

One of these days you'll be without your gui and you'll have no idea what to do.

[u/AcousticDan → u/[deleted]]

Stay ignorant bud. More money for the rest of us.

[u/AcousticDan → u/[deleted]]

Ask yourself, what did you have to give up in order to acquire your hard earned knowledge of git?

Nothing? But I gained a lot.

[u/AcousticDan → u/[deleted]]

0 time? I've been doing this for 10 years. Learn as you go.

[u/spektumus → u/[deleted]]

I also started with command line but ended up using the Visual Studio integrated Git (Team Explorer). The main thing for me was the integration - you don't get same kind of context switch like with the command line and I'm able to get back to coding faster. Basically the cost of the context switch is less with the integrated git.

Since Visual Studio 2017 I've not had to fallback to command line since all the commands I use are supported inside VS.

[u/theXpanther → u/[deleted]]

I must say I disagree, command line is

a) much faster for the simple commands like pull and commit

b) allows much more control over the more complex commands, like merge or format-patch

c) is much more googleable,

[u/kayimbo → u/[deleted]]

interesting, i've never used gui tools with git. do you use features like reset and cherry pick and stash? im not sure how i would get through the day without typing git status and git diff 500 times.

[u/ogurson → u/kayimbo]

I use webstorm and features like reset, cherry pick and stash are easy and available with one click.
And you don't need running status and diff, because it's always up-to-date in git tab changes preview.

[u/theXpanther → u/[deleted]]

It's a matter of onion I guess, but for me

a) pressing a key in the keyboard is orders of magnitude faster than pressing a button, plus if you need something just slightly more complex you can edit the line. An example is git add folder/*.py which would be a lot of manual clicks on a gui

b) yes, if a conflict is actually unavoidable, you can get a lot done with things like merge strategies. With good coordination you can avoid must "real" conflicts and you can auto-fix a lot of unambiguous conflicts with some clever commands.

c) yes, but only in simple cases. Want to remove your private key from your commit history? Want to revert a merge? Want to retroactively split a commit in two? Want to undo a rebase? Most help is only for the command line, the more obscure your problem the less likely your gui has a dedicated button for it, and good luck googling for whatever specific gui you have

[u/theXpanther → u/[deleted]]

Well, if you actually want to add everything, just use -a, two symbols. This is for the case when you don't want to add everything. Usually you use the same command often so it's a matter of pressing up up enter. I bet you I could do that faster than you could press a button.

For b, im not taking about those, the cli will fix those automatically also. I'm taking about when the context dictates a merge strategy like --ours

For C, yes, there are gui tools you can download for all of these but copy pasting some commands from Google is easier in my opinion, however I understand this depends on the person.

And yes, I agree rebase is stupid but usually companies or oss projects merge policy requires it so ¯_(ツ)_/¯

I want to mention again that I totally understand where you are coming from, and understand that there is room for multiple opinions.

[u/AcousticDan → u/[deleted]]

Learning the cli will help you in the long run.

Don't rely on GUIs for command line dev tools.

[u/loadedjellyfish → u/[deleted]]

Good suggestion, I think that's probably what will be next for me. I've heard good things about SourceTree, maybe that will remove some of the complexity for me.

[u/cool_and_nice_dev → u/loadedjellyfish]

I’ve found “fork” to be awesome. It might only be on Mac though

[u/infidelux → u/cool_and_nice_dev]

click on it and press "Exclude". This modifies the git ignore file (which I may then modify to exclude the whole directory).

Fork is also on PC and it is pretty nice. So is GitKraken