3 ms·

Thanks for your comment, its the other schemes beyond a centralised workflow that I have not arrived at yet, as I'm new to Git and not finding it friendly so fa

by j_col 15y ago

Thanks for your comment, its the other schemes beyond a centralised workflow that I have not arrived at yet, as I'm new to Git and not finding it friendly so far (despite years of experience with other systems), I probably just don't get it yet ;-)

hlidotbe 15y ago
Forget the centralized/decentralized stuff. At some point almost all git users have a somewhat centralized model. You say you don't get it yet and I think it's the issue. Coming from years of SVN I was in more or less the same situation (but I choosed to switch so it was obviously less painful). Then I started playing with local branches and funny stuff like that. I can assure you that once you get yet you'll never wan't to go back :)
JoshTriplett 15y ago
One way to look at it: in some ways Git provides a framework for almost any workflow you could possibly want. It optimizes for workflows that major users of Git care about, such as the model followed by the Linux kernel and adopted by many other projects. But Git won't enforce very much structure on you; you impose that on yourself. As a result, you can use it almost exactly like SVN, at which point it'll feel like a gratuitously different SVN. However, as you find and make use of the other possibilities available to you, you'll have more success using Git. Some of the first things you'll want to look at: doing many small commits, using many lightweight branches, and using commit --amend or rebase -i on local changes to fiddle with them before pushing them. Think of each branch as the result of your work, despite it containing many commits; you can edit the branch as a whole until you get it right, and then push it, much like you'd edit the SVN working copy until ready to run "svn commit". You get to have more structure in your working copy, and keep that structure when you push to the public repository. One big recommendation, though: learning Git works a lot like learning the UNIX command line. You can learn a pile of individual tools, but it also helps to know the philosophy of how they fit together, so you can more easily string together impressive ad-hoc solutions when you need to. I'd suggest reading more about Git's repository structure, and thinking about it more as a DAG, and how the commands fit in that model.
gruseom 15y ago
Try approaching git the way you would learn a programming language. It's more like that than an application. Git is just a good implementation of a simple, consistent, appropriate model (or you could say DSL) for version tracking. It offers this model to the user in a straightforward way. But you have to learn the model or git will seem complicated instead of simple.

by j_col 15y ago

hlidotbe 15y ago

Forget the centralized/decentralized stuff. At some point almost all git users have a somewhat centralized model. You say you don't get it yet and I think it's the issue. Coming from years of SVN I was in more or less the same situation (but I choosed to switch so it was obviously less painful). Then I started playing with local branches and funny stuff like that. I can assure you that once you get yet you'll never wan't to go back :)

JoshTriplett 15y ago

One way to look at it: in some ways Git provides a framework for almost any workflow you could possibly want. It optimizes for workflows that major users of Git care about, such as the model followed by the Linux kernel and adopted by many other projects. But Git won't enforce very much structure on you; you impose that on yourself. As a result, you can use it almost exactly like SVN, at which point it'll feel like a gratuitously different SVN. However, as you find and make use of the other possibilities available to you, you'll have more success using Git. Some of the first things you'll want to look at: doing many small commits, using many lightweight branches, and using commit --amend or rebase -i on local changes to fiddle with them before pushing them. Think of each branch as the result of your work, despite it containing many commits; you can edit the branch as a whole until you get it right, and then push it, much like you'd edit the SVN working copy until ready to run "svn commit". You get to have more structure in your working copy, and keep that structure when you push to the public repository. One big recommendation, though: learning Git works a lot like learning the UNIX command line. You can learn a pile of individual tools, but it also helps to know the philosophy of how they fit together, so you can more easily string together impressive ad-hoc solutions when you need to. I'd suggest reading more about Git's repository structure, and thinking about it more as a DAG, and how the commands fit in that model.

gruseom 15y ago

Try approaching git the way you would learn a programming language. It's more like that than an application. Git is just a good implementation of a simple, consistent, appropriate model (or you could say DSL) for version tracking. It offers this model to the user in a straightforward way. But you have to learn the model or git will seem complicated instead of simple.