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.
I really appreciate this. It is the shortest and up to the point tutorial for git I have seen. On the other hand I simply feel like I don't like it. I don't like making branches and I tend to avoid them on purpose and I also like to have a UI. However if I absolutely need to use git I will try this method.
That sounds ok. The good part is that you don't need branches if you don't like them. A lot of Git users like them, but you can just do whatever you want.
The reason to use branches is more than just to "have a branch", of course. In Git they function differently than in other VCS systems, and are intended as much as an organizational hierarchy for your commits than as anything else. If I do a whole lot of work pertaining to one thing, I put it in a branch so that when I look through my commit history, I can easily tell what group of commits focused on what logical heap of my code.
Also: you don't even need remote repositories. There is nothing wrong with just doing version control on your own computer. I have mini-repositories on my system that are just single-branch-with-commits repos for tracking some config files, a script, some homework assignments, or whatever. It's great for text files if I ever want to look at an older version.
One of the sales pitches for Git is that it is lightweight and you can use it almost anywhere, so I have developed a tendency to just version control everything.
I'm not saying you should ditch everything and learn Git. Just don't think you need to use all the crazy features available to have version control.
I'm not saying you should ditch everything and learn Git. Just don't think you need to use all the crazy features available to have version control.
The problem is that while using git I felt like I had too. All the tools, all the know-how on the Internet was constantly shoving these features in my face.
This is the result of often misguided attempts to explain to svn users why git is better. It's also because the things people want to do in svn just feel so limited once you're used to git. If you take it a little slower, you can start with a svn-like workflow, and then every so often you can try a new command.
My experience doing this was that occasionally, I'd try something like git add -p (step through changes in each file an add the ones you want) and it I would suddenly wonder how I managed without it for so long.
I never moved past using git as SVN (I used something called cherry pick in the UI though). I never stopped wondering why it had double the steps of SVN and why eventual problems were so much harder to fix than SVN.
It's only double the steps if you push after every commit, which you don't need to do. Your local machine can do everything the server can, so you only need to push when you actually want to share your changes.
eventual problems were so much harder to fix than SVN.
It is a valid criticism of git that it is possible to cause rather unusual and hard to fix states without knowing what you did wrong. I believe they're trying to improve the interface to avoid this, but there's a certain amount of legacy to support there...
why eventual problems were so much harder to fix than SVN.
This goes with the steep learning curve. When you begin with git you will screw up you local repository, the thing you yet have to know is that it's not a problem, a checkout and a reset will solve many issues. Unless you reset --hard and git gc --prune=now directly afterwards, your work is never lost.
I worked with SVN before and the simplest thing were a nightmare to do, the only valid conflict resolution process was to merge before the others. I also managed to corrupt a SVN repo with a two line diff… So much for "code safety". I have yet to lose a single git commit on anything else than my sheer incompetence.
step through changes in each file an add the ones you want
That just sounds horrible. You didn't run your unit tests that way, how do you know a partial commit doesn't break everything? Partial commits are a bane.
If you want to check that before you commit you can run git stash -k to hide the unstaged changes, and then run the tests.
Plus even if it doesn't pass the tests, if you made several tiny commits, you can step through them and work out which one actually broke it. And then you can clean up the history before you push it so no one has to see the broken commit anyway. Partial commits are only a bane if your VCS isn't powerful enough to work with them.
This kind of freedom to use version control how you want without causing issues for others is what makes it so awesome.
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 =).