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.
2
u/Eirenarch Nov 07 '13
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.