4 ms·

Everyone talks about how confusing Git is, and I think it's because they do'nt understand what the commands do. Don't get me wrong: you can royally screw up you

Everyone talks about how confusing Git is, and I think it's because they do'nt understand what the commands do. Don't get me wrong: you can royally screw up your repository with the wrong command, but 85% of your issues can be solved with checkout, pull, add, commit, push, merge, reset, status, stash, branch. When things get really heavy you may have to use rebase. And in spite of what people say, there is a nifty log that's perfect for revisiting a snapshot of your CLI's action: reflog. When I first started using Git, I was told, "When you want to make you commits public, use `git push -u origin <branch>` where branch the branch you're pushing to." That advice is technically correct, but I had no idea what -u nor origin was. I took 5 minutes to decipher the command. I walked away understand that origin an alias for the remote server, and that -u associates a remote branch with your local. I don't think Git is the greatest thing ever. I do think there's a bit of a learning curve. I also think that it's not as complicated as people make it seem. This post is a great reference for how to do X in Git, but it's a terrible source for beginners learning how to use Git. Cheat sheets are most effective when you have a basic understanding of the material.

smacktoward 8y ago
> Everyone talks about how confusing Git is, and I think it's because they do'nt understand what the commands do. If nobody understands what the commands do, the problem is with the commands, not with the people.
- dtech 8y ago
  Git has a fair share of problems, but this command is not one of them. `git push -u origin <branch>` requires you to to understand tree things: push, remotes, and branches. Once you know what those are the command is straightforward. Those concepts are very fundamental to any DCVS. Maybe you can do the first steps in other DCVS's without this knowledge * , but doing everything but the trivial things will require you to understand these concepts. It's not strange that a tool solving a complicated problem for professional developers requires a bit of investment. * But so you can in git, learning this command by rote is a valid strategy for a new git user.
- dasil003 8y ago
  It's not this simple. Git's porcelain is very unintuitive, but the underlying model is not. Once you understand the model, memorizing the commands is a relatively minor annoyance. But even if you fixed the porcelain there is essential complexity in understanding and utilizing the underlying model. To further clarify would require simplifying the model or features exposed, reducing the power of git as a tool. There are those who say you should never rebase as a form of simplifying git, but people who follow that workflow have much much messier histories than those who know how to rebase properly. A well-curated history of well-explained atomic commits has incredible value, far outstripping the cost of maintenance on a long-lived project. Git is a professional tool for software engineers, it has severe short-comings for non-coders, but as a software engineer learning it well will magnify your value.
  - smacktoward 8y ago
    If the Git developers have made an explicit decision that it's impossible to simplify the interfaces without losing some important functionality, hey, it's their software, that's their prerogative. But if that's the case, then people who have trouble understanding the interface shouldn't be called dumb, or chided for "not understanding the model," because it means the model is going to be too complicated for some people to understand. Either Git is intended to be a tool anybody can pick up and use, in which case it's shameful how thoroughly ignored widespread complaints about the UI have been; or Git is intended to be a tool for a select priesthood of Enlightened Masters, in which case it shouldn't be promoted to the unwashed masses. You can't really have it both ways. > Git is a professional tool for software engineers Lots of tools for professionals of all kinds take the time to protect their users from inadvertently harming themselves through misuse. Cars for commercial drivers aren't sold with a set of wheel chocks in place of brakes, and if you argued that they should be because they're meant for professional drivers who ought to know better than to walk away from their vehicle without setting the chocks first, you'd earn yourself a lot of funny looks.
  - krinchan 8y ago
    I got to "There are those who say you should never rebase as a form of simplifying git" and had to exert a lot of self control not to shout "YOU CAN PRY GIT REBASE INTERACTIVE OUT OF MY COLD DEAD HANDS!!" I don't understand how anyone can live without rebasing their branch on master so their PR is a fast-forward merge and squashing their 4 days of WIP and Changing Computers commits into one sane commit. Let's not even mention the fact that they introduce all those in-between commits where your unit testing is broken. Our team has a very strict rule that every commit on master has passing unit tests and all merges to master (within reason) are fast-forward merges. We also allow force pushing to your feature branch to encourage using git as a decent backup for your WIP and eventually the cleanup before merging. As such, newbies get taught the basic rebase commands. This requires talking about the underlying model of git.
norswap 8y ago
I think you don't understand what the commands do. Cheap jab aside, yeah git is fine 99% of the time. But that last 1% can really fuck you. 1% is not that small percentage.
alexeiz 8y ago
> you can royally screw up your repository with the wrong command You already mentioned the reflog, which makes Git screw ups a non-issue. But the only time I seriously messed up something was when I used Git commands without full understanding what they actually did (two weeks into learning Git). This was mitigated by RTFM, which clearly explained what I did wrong. Since then I never listen to advises like 'just use this git command', but read the manual first. I noticed that most people who have problems with Git don't understand basic Git concepts like branch, remote, staging, commit, ref. These concepts are really not that hard. Once you get familiar with them everything else with Git is a breeze. But I'm surprised how stubborn people are at not willing to spend a little time to learn. They just want you to tell them Git commands. But Git commands are not important. I personally don't remember exact command parameters, because I can always look them up in the man page. Git concepts is what makes you proficient with Git.

smacktoward 8y ago

> Everyone talks about how confusing Git is, and I think it's because they do'nt understand what the commands do. If nobody understands what the commands do, the problem is with the commands, not with the people.

dtech 8y ago
Git has a fair share of problems, but this command is not one of them. `git push -u origin <branch>` requires you to to understand tree things: push, remotes, and branches. Once you know what those are the command is straightforward. Those concepts are very fundamental to any DCVS. Maybe you can do the first steps in other DCVS's without this knowledge * , but doing everything but the trivial things will require you to understand these concepts. It's not strange that a tool solving a complicated problem for professional developers requires a bit of investment. * But so you can in git, learning this command by rote is a valid strategy for a new git user.
dasil003 8y ago
It's not this simple. Git's porcelain is very unintuitive, but the underlying model is not. Once you understand the model, memorizing the commands is a relatively minor annoyance. But even if you fixed the porcelain there is essential complexity in understanding and utilizing the underlying model. To further clarify would require simplifying the model or features exposed, reducing the power of git as a tool. There are those who say you should never rebase as a form of simplifying git, but people who follow that workflow have much much messier histories than those who know how to rebase properly. A well-curated history of well-explained atomic commits has incredible value, far outstripping the cost of maintenance on a long-lived project. Git is a professional tool for software engineers, it has severe short-comings for non-coders, but as a software engineer learning it well will magnify your value.
- smacktoward 8y ago
  If the Git developers have made an explicit decision that it's impossible to simplify the interfaces without losing some important functionality, hey, it's their software, that's their prerogative. But if that's the case, then people who have trouble understanding the interface shouldn't be called dumb, or chided for "not understanding the model," because it means the model is going to be too complicated for some people to understand. Either Git is intended to be a tool anybody can pick up and use, in which case it's shameful how thoroughly ignored widespread complaints about the UI have been; or Git is intended to be a tool for a select priesthood of Enlightened Masters, in which case it shouldn't be promoted to the unwashed masses. You can't really have it both ways. > Git is a professional tool for software engineers Lots of tools for professionals of all kinds take the time to protect their users from inadvertently harming themselves through misuse. Cars for commercial drivers aren't sold with a set of wheel chocks in place of brakes, and if you argued that they should be because they're meant for professional drivers who ought to know better than to walk away from their vehicle without setting the chocks first, you'd earn yourself a lot of funny looks.
- krinchan 8y ago
  I got to "There are those who say you should never rebase as a form of simplifying git" and had to exert a lot of self control not to shout "YOU CAN PRY GIT REBASE INTERACTIVE OUT OF MY COLD DEAD HANDS!!" I don't understand how anyone can live without rebasing their branch on master so their PR is a fast-forward merge and squashing their 4 days of WIP and Changing Computers commits into one sane commit. Let's not even mention the fact that they introduce all those in-between commits where your unit testing is broken. Our team has a very strict rule that every commit on master has passing unit tests and all merges to master (within reason) are fast-forward merges. We also allow force pushing to your feature branch to encourage using git as a decent backup for your WIP and eventually the cleanup before merging. As such, newbies get taught the basic rebase commands. This requires talking about the underlying model of git.

norswap 8y ago

I think you don't understand what the commands do. Cheap jab aside, yeah git is fine 99% of the time. But that last 1% can really fuck you. 1% is not that small percentage.

alexeiz 8y ago

> you can royally screw up your repository with the wrong command You already mentioned the reflog, which makes Git screw ups a non-issue. But the only time I seriously messed up something was when I used Git commands without full understanding what they actually did (two weeks into learning Git). This was mitigated by RTFM, which clearly explained what I did wrong. Since then I never listen to advises like 'just use this git command', but read the manual first. I noticed that most people who have problems with Git don't understand basic Git concepts like branch, remote, staging, commit, ref. These concepts are really not that hard. Once you get familiar with them everything else with Git is a breeze. But I'm surprised how stubborn people are at not willing to spend a little time to learn. They just want you to tell them Git commands. But Git commands are not important. I personally don't remember exact command parameters, because I can always look them up in the man page. Git concepts is what makes you proficient with Git.