4 ms·

I've used svn and git a little and am shopping around for something to use on a current project. I found git harder to use than svn, given that I'm not a power

I've used svn and git a little and am shopping around for something to use on a current project. I found git harder to use than svn, given that I'm not a power user. I noted that the last item on the page seems to reflect that--git is only easier to learn than perforce, according to the site. Is that really true? I might just be dumb, but I had a harder time with git. Given that I'm in mostly single-user mode, it seems like I might be more productive with svn simply because I wouldn't have to wrestle with it as much to get going. Can anyone recommend a "git for people who can understand and operate svn without hurting themselves?" guide? Or is the value of git significantly lessened in single-user mode?

schacon 18y ago
I generally like to try my best to get people to completely forget SVN when learning Git, because I feel that SVN is fundamentally a bad model, BUT - http://git.or.cz/course/svn.html http://git.or.cz/course/svn.html may be what you're looking for. When you want to really learn Git better (and gain hugely in productivity) check out http://gitcasts.com http://gitcasts.com and http://book.git-scm.com http://book.git-scm.com for some Git-specific learning materials.
- justindz 18y ago
  Thanks to all replies for feedback. I think I will try Git again. Any recommendations on a UI tool (or recommend that I don't use one?). I run Ubuntu and have Vista on my work laptop. If there's a good tool for simplifying adds and commits and what not, I'd like to try that. I think part of my problem might have been that I tried to learn Git using Github, which made a multi-user situation out of a single-user situation and was unnecessarily complex. For my current project, the source is not public so I can't have that problem ;-)
  - schacon 18y ago
    'git gui' is a bit ugly, but it's actually a pretty nice ui in terms of functionality. give that a try, it comes with git. if you want a little primer from a windows perspective, i did a gitcast on installing git on windows and using the 'git gui' here : http://gitcasts.com/posts/git-on-windows http://gitcasts.com/posts/git-on-windows
deleted 18y ago
[deleted]
deleted 18y ago
[deleted]
defunkt 18y ago
The biggest problem people have with Git is unlearning Subversion. 'git revert' is not 'svn revert,' 'git checkout' is not 'svn checkout,' etc - if you want to learn Git, leave everything you know about Subversion at the door and go in with an open mind.
mechanical_fish 18y ago
The Peepcode screencast on git was very good.
biohacker42 18y ago
The value of git in team mode is so great that you could say it is significantly lessened in single-user mode. However, I would still invest the time to learn git, and yes it is more complex then svn. Like 10 fingered typing git is something you don't necessarily need, but it is a multiplier on your productivity.
kqr2 18y ago
I know what you mean, but like learning anything else, it takes some practice to get used to it. You've probably seem some of these links before. http://git.or.cz/course/svn.html http://git.or.cz/course/svn.html http://cworth.org/hgbook-git/tour/ http://cworth.org/hgbook-git/tour/ http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html http://www-cs-students.stanford.edu/~blynn/gitmagic/index.ht...
gcv 18y ago
If you really just want a minimal source control system, Git does the trick well enough. I don't think you need anything more than 'git init' (make a fresh project), 'git commit -a' (commit all new changes except for deleted or renamed files), 'git add' (to add new files), 'git rm' (to remove files), 'git checkout' (for reverting changes), 'git log' (obvious), and 'git diff' (also hopefully obvious). Put a .gitignore file in the root of your project listing globbed filenames for everything you don't want to manage. Run 'git commit' after every sequence of 'git add' or 'git rm' invocations. That's it. You shouldn't need any more documentation than this paragraph. Branching is a killer feature, as is clean history management, as is the index, and when you find yourself wishing more control over what happens to your source code, wishing for freedom to experiment, all these tools will be there waiting for you.
- nostrademons 18y ago
  'git mv' for moving files, and I'm overly dependent upon 'git status' for checking what's changed.
  - gcv 18y ago
    Agreed on both points, although 'git mv' is optional. As long as the old file is 'git rm'ed and the new file is 'git add'ed in the same commit, git detects the rename quite reliably.
  - jrockway 18y ago
    mv is just sugar, though, you can easily copy the file using unix "cp" and delete/add to get the same result. Git does not track renames.
    - etal 18y ago
      Or, just use the Unix mv, and let Git figure out what you did at the next "git add .".
- maw 18y ago
  'git diff' (also hopefully obvious) Except it's not, since it'll output different things depending on whether you have staged anything or not. This behavior is sometimes useful, but hardly obvious. Many aspects of git are like this, and it's frustrating, speaking as someone who slowly came around to git and now likes it quite a bit and would recommend it, to see its advocates forget or try to talk around just how difficult it is to learn. (1.5 and 1.6 may have improvements, but the claim that git's now roughly as easy to learn as hg or bzr, especially without understanding its internals, is absurd.)
johnm 18y ago
If you're coming from svn then Mercurial is much easier to learn than Git. Also, I don't know what crack they are smoking but Perforce is easier to learn than Git for basic stuff. The biggest place that I've seen perforce get complex is where people try to enforce all sorts of bizarre (read: stupid, useless) polices.
mooneater 18y ago
One night 4 months ago, I found myself terrified by the reality that I due to what was happening with our clients, I needed to fork the codebase. And I was on svn. Ouch. I had postponed this moment as long as possible using the svn-without-branches approach. But that wasnt going to help me going fwd. That night I figured I had no choice but to plunge into git asap. I was not looking forward to it AT ALL; It seemed at best a necessary cost. Once I decided to, it took me under 3 days to mostly "get" git and be productive. (And I would not say I am the quickest learner.) Now I would never, ever, ever go back, even for tiny projects. Key resources for me: - gitcasts for the basics - git channel on IRC for odd questions - git internals from peepcode for a more solid understanding Best of luck!
iamwil 18y ago
Git has some learning curve, since you have to discard your notions of Svn, and learn how Git models a repository. But once you grasp that, it's pretty easy, not to mention pretty powerful. For me, Git had certain features that gave me a "wow", as I learned about and got use to using them: 1) Local branching - branching is fast, and merging is relatively painless. This lets you experiment with things without affecting the main branch. Branches are like 'tabs' on my browser, but for my source control. git checkout -b experimental_branch 2) Staging commits - You can fix little things that might not have to do with your current ticket, but add them to separate commits. You can do even split edits done to the same file to two different commits. git add -i 3) Rebasing branches - You can move the root of the local branch if you want the changes since then. Even better, you can reorder the commits as long as you haven't pushed it to a remote repository yet. The same task allows you to squash your commits together for a cleaner history. git rebase -i 4) Stashing changes - You can stash uncommitted changes, so that you can perform other operations that require no uncommitted changes. This is useful when you're working on something, but can't commit it to your local branch yet, and something needs fixing on production right now. git stash Basically, a lot of what Git enables me to do is switch between tasks easily.
- tdavis 18y ago
  Basically, a lot of what Git enables me to do is switch between tasks easily. As a single developer, I love this about git. Being able to instantly create a new local branch to work on something, even if I only have an hour or two to devote to it, then switching branches and continuing on with the next important task is awesome. At least for me, it basically encourages exploration and testing new ideas because it takes no time and I know the "real" code is still safe and accessible instantly.

schacon 18y ago

I generally like to try my best to get people to completely forget SVN when learning Git, because I feel that SVN is fundamentally a bad model, BUT - http://git.or.cz/course/svn.html http://git.or.cz/course/svn.html may be what you're looking for. When you want to really learn Git better (and gain hugely in productivity) check out http://gitcasts.com http://gitcasts.com and http://book.git-scm.com http://book.git-scm.com for some Git-specific learning materials.

justindz 18y ago
Thanks to all replies for feedback. I think I will try Git again. Any recommendations on a UI tool (or recommend that I don't use one?). I run Ubuntu and have Vista on my work laptop. If there's a good tool for simplifying adds and commits and what not, I'd like to try that. I think part of my problem might have been that I tried to learn Git using Github, which made a multi-user situation out of a single-user situation and was unnecessarily complex. For my current project, the source is not public so I can't have that problem ;-)
- schacon 18y ago
  'git gui' is a bit ugly, but it's actually a pretty nice ui in terms of functionality. give that a try, it comes with git. if you want a little primer from a windows perspective, i did a gitcast on installing git on windows and using the 'git gui' here : http://gitcasts.com/posts/git-on-windows http://gitcasts.com/posts/git-on-windows

deleted 18y ago

[deleted]

deleted 18y ago

[deleted]

defunkt 18y ago

The biggest problem people have with Git is unlearning Subversion. 'git revert' is not 'svn revert,' 'git checkout' is not 'svn checkout,' etc - if you want to learn Git, leave everything you know about Subversion at the door and go in with an open mind.

mechanical_fish 18y ago

The Peepcode screencast on git was very good.

biohacker42 18y ago

The value of git in team mode is so great that you could say it is significantly lessened in single-user mode. However, I would still invest the time to learn git, and yes it is more complex then svn. Like 10 fingered typing git is something you don't necessarily need, but it is a multiplier on your productivity.

kqr2 18y ago

I know what you mean, but like learning anything else, it takes some practice to get used to it. You've probably seem some of these links before. http://git.or.cz/course/svn.html http://git.or.cz/course/svn.html http://cworth.org/hgbook-git/tour/ http://cworth.org/hgbook-git/tour/ http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html http://www-cs-students.stanford.edu/~blynn/gitmagic/index.ht...

gcv 18y ago

If you really just want a minimal source control system, Git does the trick well enough. I don't think you need anything more than 'git init' (make a fresh project), 'git commit -a' (commit all new changes except for deleted or renamed files), 'git add' (to add new files), 'git rm' (to remove files), 'git checkout' (for reverting changes), 'git log' (obvious), and 'git diff' (also hopefully obvious). Put a .gitignore file in the root of your project listing globbed filenames for everything you don't want to manage. Run 'git commit' after every sequence of 'git add' or 'git rm' invocations. That's it. You shouldn't need any more documentation than this paragraph. Branching is a killer feature, as is clean history management, as is the index, and when you find yourself wishing more control over what happens to your source code, wishing for freedom to experiment, all these tools will be there waiting for you.

nostrademons 18y ago
'git mv' for moving files, and I'm overly dependent upon 'git status' for checking what's changed.
- gcv 18y ago
  Agreed on both points, although 'git mv' is optional. As long as the old file is 'git rm'ed and the new file is 'git add'ed in the same commit, git detects the rename quite reliably.
- jrockway 18y ago
  mv is just sugar, though, you can easily copy the file using unix "cp" and delete/add to get the same result. Git does not track renames.
  - etal 18y ago
    Or, just use the Unix mv, and let Git figure out what you did at the next "git add .".
maw 18y ago
'git diff' (also hopefully obvious) Except it's not, since it'll output different things depending on whether you have staged anything or not. This behavior is sometimes useful, but hardly obvious. Many aspects of git are like this, and it's frustrating, speaking as someone who slowly came around to git and now likes it quite a bit and would recommend it, to see its advocates forget or try to talk around just how difficult it is to learn. (1.5 and 1.6 may have improvements, but the claim that git's now roughly as easy to learn as hg or bzr, especially without understanding its internals, is absurd.)

johnm 18y ago

If you're coming from svn then Mercurial is much easier to learn than Git. Also, I don't know what crack they are smoking but Perforce is easier to learn than Git for basic stuff. The biggest place that I've seen perforce get complex is where people try to enforce all sorts of bizarre (read: stupid, useless) polices.

mooneater 18y ago

One night 4 months ago, I found myself terrified by the reality that I due to what was happening with our clients, I needed to fork the codebase. And I was on svn. Ouch. I had postponed this moment as long as possible using the svn-without-branches approach. But that wasnt going to help me going fwd. That night I figured I had no choice but to plunge into git asap. I was not looking forward to it AT ALL; It seemed at best a necessary cost. Once I decided to, it took me under 3 days to mostly "get" git and be productive. (And I would not say I am the quickest learner.) Now I would never, ever, ever go back, even for tiny projects. Key resources for me: - gitcasts for the basics - git channel on IRC for odd questions - git internals from peepcode for a more solid understanding Best of luck!

iamwil 18y ago

Git has some learning curve, since you have to discard your notions of Svn, and learn how Git models a repository. But once you grasp that, it's pretty easy, not to mention pretty powerful. For me, Git had certain features that gave me a "wow", as I learned about and got use to using them: 1) Local branching - branching is fast, and merging is relatively painless. This lets you experiment with things without affecting the main branch. Branches are like 'tabs' on my browser, but for my source control. git checkout -b experimental_branch 2) Staging commits - You can fix little things that might not have to do with your current ticket, but add them to separate commits. You can do even split edits done to the same file to two different commits. git add -i 3) Rebasing branches - You can move the root of the local branch if you want the changes since then. Even better, you can reorder the commits as long as you haven't pushed it to a remote repository yet. The same task allows you to squash your commits together for a cleaner history. git rebase -i 4) Stashing changes - You can stash uncommitted changes, so that you can perform other operations that require no uncommitted changes. This is useful when you're working on something, but can't commit it to your local branch yet, and something needs fixing on production right now. git stash Basically, a lot of what Git enables me to do is switch between tasks easily.

tdavis 18y ago
Basically, a lot of what Git enables me to do is switch between tasks easily. As a single developer, I love this about git. Being able to instantly create a new local branch to work on something, even if I only have an hour or two to devote to it, then switching branches and continuing on with the next important task is awesome. At least for me, it basically encourages exploration and testing new ideas because it takes no time and I know the "real" code is still safe and accessible instantly.