3 ms·

Just for the learning part, I moved from CVS to Perforce 10 years ago in a new job and it took me perhaps all of 4 hours to completely understand the work flow

Just for the learning part, I moved from CVS to Perforce 10 years ago in a new job and it took me perhaps all of 4 hours to completely understand the work flow and the GUI. Until now when I started to see what Git is all about and after a couple of days and lots of different clients and articles, I am still not sure about my Git skills. It's certainly isn't as straightforward to learn and use.

ams6110 10y ago
That's OK, I've been using git for a couple of years and I still don't understand it.
- srd 10y ago
  I guess this is because there are so many more exposed levels of git to learn. The introductory chapters in git books about all the "this is how a commit hash is computed" and "it's all about the content, not the filename" is good if you want to know whats going on on the lower levels, but for git newbies it's more confusing than helpful. The git concepts you need to know that are non-obvious are: - there is no special branch, "master" is just a default name - there is no special "central" repository on a technical level - all git commits have one or more parents, but they don't know what branch they're from (i.e. reverting a merge can be a pain) - a git commit always represents an entire project tree, you can't version individual files like subversion does Unless you're planning on spelunking into the plumbing commands (i.e. low level stuff exposed to shell commands), small parts of the porcellain commands (i.e. that the end user should use) is more then enough to work with git and understand the "how I need to work with git" flow: The commands I use 95% of the time are: - git init - git add - git commit (and git commit --amend when I didn't pay attention) - git rm - git checkout - git branch - git pull - git push and most without any commandline options. These command invocations you should be able to learn within 4 hours, especially if you've used an SCM before. (and the git <command> --help pages are actually well written, once you know what you want to do). Sure it's nice to know about git add --patch, or git rebase --interactive, but do you really need them to work well with git? I don't think so. If you're inclined to learn more about your tools, sure, go ahead. But thats something that comes with years of use and doesn't have to happen up front.
  - CannisterFlux 10y ago
    My top git commands from the commandline history are git status, git commit -a, git diff, git gui, gitk --all. There are a few git pull/pushes in there, but these 5 dominate. I hardly ever use git add, and over the years I've pretty much stopped using the index altogether. The GUI tools are my way of doing the fancy stuff. They work great and expose a lot of the more complex features without having to remember all the command line options.
  - rmgraham 10y ago
    I find that knowing how it works is the only way the commands and flags make any sense. I am constantly seeing people around me fumble through git trying to get by on a handful of commands they've memorized and just live with the fact that they need to re-clone their repo every now and then. These people scare me. How can they be comfortable not even knowing what they are telling git to do? I taught myself how the DAG worked, then the low level commands to manipulate it. Now when I read the docs I get nice surprises like pre-built commands for doing the series of operations I plotted out in my head (most recently 'git merge --no-commit' instead of read-tree, update-index, write-tree)... Oh god, I've become that guy in college who refuses to use a CRC library until he understands the proof. But seriously, I'm genuinely amazed people can use git at all without understanding it completely. The mnemonics make zero sense without background, and the operations are completely arbitrary looking.
    - pjc50 10y ago
      I'm genuinely amazed people can use git at all without understanding it completely. The mnemonics make zero sense without background, and the operations are completely arbitrary looking. Remember, most things people use every day without understanding them completely. This is a huge barrier to entry and effective use of git; you can't require people to spend weeks learning it before they commit a single line of code. So yes, people learn sets of runes that work, and know that if you step off the path there's no easy way of working out what happened let alone undoing it without blowing away the local copy and going back to the master.
      - 10y ago
yxhuvud 10y ago
The thing about git is that it is a very open ended tool that doesn't enforce any one work-flow. Find one that suits you and your workplace, and then slowly accumulate tricks that make things simpler to reason about.
- stevoski 10y ago
  When I was new to git I had to choose a workflow while not having sufficient knowledge or experience with git to do so. It was frustrating. I wish there had been some sort of conventional workflow I could have adopted for my situation. It took a year of using git daily until I was felt able to choose a workflow that was appropriate for my little company.
IshKebab 10y ago
I highly recommend using SourceTree. It's quite slow, but at least it is understandable. Command-line git just sucks. Partly because the interface is just badly written and inconsistent (Mercurial is much better for example), and partly because version control just fundamentally benefits from a graphical interface, in the same way that a web browser would for example. Only a madman would use wget to browse the web (yes I know about him). You'd have to be nearly as mad to want to use the git command line.
- donatj 10y ago
  There is incredible power in the git command line and to simply write it off is silly. If you take the time to learn a bit about how it works under the hood it makes a lot more sense. When you truly understand that it is just a directed graph, along with blobs, and trees. All of which are represented by hashes. Dig in because your seriously missing out just using a GUI.

ams6110 10y ago

That's OK, I've been using git for a couple of years and I still don't understand it.

srd 10y ago
I guess this is because there are so many more exposed levels of git to learn. The introductory chapters in git books about all the "this is how a commit hash is computed" and "it's all about the content, not the filename" is good if you want to know whats going on on the lower levels, but for git newbies it's more confusing than helpful. The git concepts you need to know that are non-obvious are: - there is no special branch, "master" is just a default name - there is no special "central" repository on a technical level - all git commits have one or more parents, but they don't know what branch they're from (i.e. reverting a merge can be a pain) - a git commit always represents an entire project tree, you can't version individual files like subversion does Unless you're planning on spelunking into the plumbing commands (i.e. low level stuff exposed to shell commands), small parts of the porcellain commands (i.e. that the end user should use) is more then enough to work with git and understand the "how I need to work with git" flow: The commands I use 95% of the time are: - git init - git add - git commit (and git commit --amend when I didn't pay attention) - git rm - git checkout - git branch - git pull - git push and most without any commandline options. These command invocations you should be able to learn within 4 hours, especially if you've used an SCM before. (and the git <command> --help pages are actually well written, once you know what you want to do). Sure it's nice to know about git add --patch, or git rebase --interactive, but do you really need them to work well with git? I don't think so. If you're inclined to learn more about your tools, sure, go ahead. But thats something that comes with years of use and doesn't have to happen up front.
- CannisterFlux 10y ago
  My top git commands from the commandline history are git status, git commit -a, git diff, git gui, gitk --all. There are a few git pull/pushes in there, but these 5 dominate. I hardly ever use git add, and over the years I've pretty much stopped using the index altogether. The GUI tools are my way of doing the fancy stuff. They work great and expose a lot of the more complex features without having to remember all the command line options.
- rmgraham 10y ago
  I find that knowing how it works is the only way the commands and flags make any sense. I am constantly seeing people around me fumble through git trying to get by on a handful of commands they've memorized and just live with the fact that they need to re-clone their repo every now and then. These people scare me. How can they be comfortable not even knowing what they are telling git to do? I taught myself how the DAG worked, then the low level commands to manipulate it. Now when I read the docs I get nice surprises like pre-built commands for doing the series of operations I plotted out in my head (most recently 'git merge --no-commit' instead of read-tree, update-index, write-tree)... Oh god, I've become that guy in college who refuses to use a CRC library until he understands the proof. But seriously, I'm genuinely amazed people can use git at all without understanding it completely. The mnemonics make zero sense without background, and the operations are completely arbitrary looking.
  - pjc50 10y ago
    I'm genuinely amazed people can use git at all without understanding it completely. The mnemonics make zero sense without background, and the operations are completely arbitrary looking. Remember, most things people use every day without understanding them completely. This is a huge barrier to entry and effective use of git; you can't require people to spend weeks learning it before they commit a single line of code. So yes, people learn sets of runes that work, and know that if you step off the path there's no easy way of working out what happened let alone undoing it without blowing away the local copy and going back to the master.
    - 10y ago

yxhuvud 10y ago

The thing about git is that it is a very open ended tool that doesn't enforce any one work-flow. Find one that suits you and your workplace, and then slowly accumulate tricks that make things simpler to reason about.

stevoski 10y ago
When I was new to git I had to choose a workflow while not having sufficient knowledge or experience with git to do so. It was frustrating. I wish there had been some sort of conventional workflow I could have adopted for my situation. It took a year of using git daily until I was felt able to choose a workflow that was appropriate for my little company.

IshKebab 10y ago

I highly recommend using SourceTree. It's quite slow, but at least it is understandable. Command-line git just sucks. Partly because the interface is just badly written and inconsistent (Mercurial is much better for example), and partly because version control just fundamentally benefits from a graphical interface, in the same way that a web browser would for example. Only a madman would use wget to browse the web (yes I know about him). You'd have to be nearly as mad to want to use the git command line.

donatj 10y ago
There is incredible power in the git command line and to simply write it off is silly. If you take the time to learn a bit about how it works under the hood it makes a lot more sense. When you truly understand that it is just a directed graph, along with blobs, and trees. All of which are represented by hashes. Dig in because your seriously missing out just using a GUI.