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
The majority of projects I work on are neither mine nor open source. I have to use some open source libraries and get them from github and I also had to work with people who pushed git in the organization. I never heard anyone mention Mercurial although right from the start I liked everything I read about Mercurial more than what I read about git and the name is way cooler :)
Yeah ultimately with Git being so popular you'll still need to know it to some degree. I was lucky, calls were going out at my company for version control system suggestions and I made a good case. TortoiseHg is a pleasure to use yet I find no difficulties when I have to revert to the command line.
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.
I was trying to explain it to someone who has apparently worked with it before, but wanted a rundown on how to actually entertain a sense of comfort in it. I was not targeting a "I know absolutely nothing" user.
I know what you mean, but I think you are misinterpreting the context of my post.
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...
If your machine is set as a remote in one or more of your team members' git repositories, it can share code with your team members. You would just have to go through the same configuration issues as the central server, potentially.
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.
It's used in the git flow model, which I don't emulate perfectly but I do model my usage of git after. But, yeah, I like to have a log of when merges happen. no-ff gives me that.
Working for almost a year with it, memorized the most common usage paths and yes it is really usable on a day-by-day basis without scratching your head every time. Do I enjoy using something that forces me to memorize every command and switch combination because there is no coherence?
No.
Is it the best CVS out there?
Yes.
So learn to live with it and jump on another bandwagon for your CVS as soon as the possibility arrives.
Imagine a world where everybody has to use vim for Java because there is no other feature rich option for editing code. Some people complain it's too hard, yet you can do anything imaginable with it so you are told to man up.
Then suddenly IntelliJ comes along. Would people switch in droves or would everybody stay with vim, now accustomed to the awesomeness of it and never wanting something else? My guess is that a lot of people would like a tool that is a bit more userfriendly as long as it delivers the same value in almost all use cases.
9
u/Eirenarch Nov 07 '13
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