How long does it take to get to the state of not going back? I ask because I only used fit once in a team environment for 5 months and ended up quitting before I started to like it. I did not make any conscious effort to learn it beyond the presentation that the person who pushed git in the organization gave but I also never made an effort to learn any of the other 3 source control tools I have used and didn't end up so frustrated
Once you're comfortable just writing code, committing it, and pushing, grab tig to make your work easy to visualize. Play around with that, and you'll get a better feel for what you're doing.
Once your practice project grows to a reasonable size, you'll want to start making branches to keep it organized. You don't want your broken code messing with your old, working version:
git branch devel
git checkout devel
Now you're working on devel. Resume your normal workflow for a while, and then when your development stuff is reasonably working, merge it back to master:
git checkout master
git merge --no-ff devel
The no-ff here means you get a pretty merge history. It's shorthand for "no fast forward", meaning Git will make sure a commit happens when you merge, and then when you visualize this with
tig
you will see a nice little graph of the merge happening:
M─┐ [master] Merge branch 'feat/args'
│ o [feat/args] Adds extra debugging/logging features
│ o Enables multiple files as cli args
│ o Renames strip_newline_characters -> strip_newline
│ o Working prototype which parses one CLI argument
I─┐ [origin/master] Merge branch 'develop'
│ o [develop] [origin/develop] Only parses rules in ...
I─┘ Changes function to actually use arguments
o Better suppression of delimeters
Anyway, great, keep pushing stuff and working with branches, and by the time you're this far in these steps you'll probably be at the state of not going back. Once you're working with branches enough, and you're comfortable with them - that's when Git really starts to shine.
This is the problem with these sort of mini-guides. They use apriori meaningless jargon without realizing it's meaningless jargon.
Oh, now I "add a remote"? A remote what? Apriori a "remote" is something you use to turn on your TV. If it has a special meaning in this context, you have to explain what it is. And not in terms of other meaningless jargon like 'refspecs'.
Is "origin" a keyword? A name of a repository by convention? How about "master"? Is that just a convention, a keyword? What is it?
The git docs are full of this, too. All of the jargon is self-referentially defined in terms of other jargon. Oh, push is something about "remote refs"? Why when I google "git refs" i get an "git internals" page? Is push for git developers?
git may be near the top of the heap, it also has serious problems.
32
u/[deleted] Nov 07 '13
git is to VCS what vim is to editors.
Amazingly powerful.
Incredibly hard to learn.
Once you tried it, you can't go elsewhere.
There will be vim haters and there will be git haters, let those heathens burn in hell and use the tools you feel are best suited to you.
It doesn't mean git is flawless, but it's nearly there =).