4 ms·

For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the

by tikhonj 15y ago

For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day. Another benefit I've found--as a student with an internet connection that isn't always on--is that I can still commit without it. It's also much easier to use branches in Git. If I want to try something weird, or temporarily break some code, it's trivial just to create and use a new branch. Ultimately, the reason you're not seeing much of an advantage to Git right now is because (from a user's standpoint) it's basically a superset of SVN. Once you get used to it and learn more about it, chances are you'll start improving your workflow to take advantage of more of its features. Git can basically support the same workflow as a centralized system, but it also supports other scheme.

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.
nupark2 15y ago
> For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day. This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs. Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit. Just commit as you go along. If you're doing something that outright breaks the build or is disruptive, then create a branch -- it's not hard (see below). > It's also much easier to use branches in Git. If I want to try something weird, or temporarily break some code, it's trivial just to create and use a new branch. I don't really understand why git users keep repeating this trope. Here's my SVN branching process: svn cp ^/trunk ^/branches/some-branch svn switch ^/branches/some-branch And then at some future time (or many future times) I can merge in the latest trunk changes (or vis versa). SVN has merge tracking, so it Just Works: svn merge ^/trunk I can only assume that this idea that "branches are hard in SVN" is a relic of a time when SVN didn't have merge tracking -- the feature was introduced nearly 4 years ago. > Git can basically support the same workflow as a centralized system, but it also supports other scheme. It can, but with more work. I guess I could just alias 'git commit' to 'git commit && git push', but then why am I not just using SVN?
- deleted 15y ago
  [deleted]
- chousuke 15y ago
  > This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs. Git is decentralised. If you think you might get conflicts with some other developer, just ask them to push their branch somewhere public where you can fetch their work and look at what they're doing. Or they can export their commits as a tarball and bring it to you on a USB drive if you have no network connectivity for some reason. :P > Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit. To be honest, this still sounds like a workflow problem. if "Implemented X" is too huge to be a single commit, then the person who pushed it was lazy and didn't bother to spend enough time to make good commits. If it really only "implements X", then even if it is big, it's at least self-contained. You should spend time thinking about what you commit. It's not just a matter of getting your code somewhere safe; the code in your working directory is the raw material from which you create a new snapshot of the project that represents an improvement. This is really difficult to do with SVN, but it should be your default workflow in git. It's more work beforehand, but it improves code maintainability and makes bisecting more effective. It's likely that most developers are not disciplined enough to do this for every commit while they're coding. Fortunately, rebasing allows you to defer all that work to just before you push. Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project. How the development actually happened is completely uninteresting in git. Ideally the log is a history of patches applied to the project, each of which changes only one thing, and is complete by itself (later commits can depend on earlier ones, but the reverse should not be true)

by tikhonj 15y ago

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.

nupark2 15y ago

> For one, you can have much more atomic commits, which can help with maintaining the code and finding and fixing bugs. Just push all of your small commits at the end of the day. This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs. Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit. Just commit as you go along. If you're doing something that outright breaks the build or is disruptive, then create a branch -- it's not hard (see below). > It's also much easier to use branches in Git. If I want to try something weird, or temporarily break some code, it's trivial just to create and use a new branch. I don't really understand why git users keep repeating this trope. Here's my SVN branching process: svn cp ^/trunk ^/branches/some-branch svn switch ^/branches/some-branch And then at some future time (or many future times) I can merge in the latest trunk changes (or vis versa). SVN has merge tracking, so it Just Works: svn merge ^/trunk I can only assume that this idea that "branches are hard in SVN" is a relic of a time when SVN didn't have merge tracking -- the feature was introduced nearly 4 years ago. > Git can basically support the same workflow as a centralized system, but it also supports other scheme. It can, but with more work. I guess I could just alias 'git commit' to 'git commit && git push', but then why am I not just using SVN?

deleted 15y ago
[deleted]
chousuke 15y ago
> This makes it REALLY HARD to keep up with your team members' code, because all you see are huge commit batches at the end of the day containing tons of diffs. Git is decentralised. If you think you might get conflicts with some other developer, just ask them to push their branch somewhere public where you can fetch their work and look at what they're doing. Or they can export their commits as a tarball and bring it to you on a USB drive if you have no network connectivity for some reason. :P > Worse yet, sometimes people use rebase to hide the intermediate commits and you get one huge "Implemented X" commit. To be honest, this still sounds like a workflow problem. if "Implemented X" is too huge to be a single commit, then the person who pushed it was lazy and didn't bother to spend enough time to make good commits. If it really only "implements X", then even if it is big, it's at least self-contained. You should spend time thinking about what you commit. It's not just a matter of getting your code somewhere safe; the code in your working directory is the raw material from which you create a new snapshot of the project that represents an improvement. This is really difficult to do with SVN, but it should be your default workflow in git. It's more work beforehand, but it improves code maintainability and makes bisecting more effective. It's likely that most developers are not disciplined enough to do this for every commit while they're coding. Fortunately, rebasing allows you to defer all that work to just before you push. Not rebasing and just pushing loads of small commits makes it more likely that you will not have a clear history of progression for the project. How the development actually happened is completely uninteresting in git. Ideally the log is a history of patches applied to the project, each of which changes only one thing, and is complete by itself (later commits can depend on earlier ones, but the reverse should not be true)