6 ms·

Speaking as a long-term Subversion and Perforce user, I'm finding the switch to Git (forced on me by a job change) painful. My old work flow: 1. Commit my code

by j_col 15y ago

Speaking as a long-term Subversion and Perforce user, I'm finding the switch to Git (forced on me by a job change) painful. My old work flow: 1. Commit my code to the central repo. My new and "improved" Git workflow: 1. Commit my code to my local branch. 2. Push my local branch to the central repo. As we're using Git as a centralised source control anyway, what is this extra work saving me over using a "traditional" centralised source control? In other words, what's the point in using a decentralised source control system in a centralised manner, and how many teams are truly using Git in a decentralised manner?

jlongster 15y ago
It's saving you because you can freely commit without ever running into a conflict suprisingly. Deal with the merges and conflicts when you want to. Also, it's lot faster to commit. You shouldn't be pushing out every commit -- just commit a lot and when you want others to see it, push it.
- j_col 15y ago
  I could commit pretty freely using Subversion or Perforce to. As for the faster Git commits, is that just because you are only commiting locally? You still have the overhead of pushing to your central repo. Reading the original article, it seems his reason for switching to Git can be summed up in one word: Github.
  - jaggederest 15y ago
    > I could commit pretty freely using Subversion or Perforce to. Pretty freely is not freely. That's like having 'decent' freedom of speech, y'see. Git allows you to commit any time, so fast you won't even notice the pause. > As for the faster Git commits, is that just because you are only commiting locally? You still have the overhead of pushing to your central repo. Yes, it's faster because it only commits locally. You should not push every commit to the central repo, and you should be committing more or less every time you change a file. Git allows you to be far more granular than SVN or perforce did. It also allows you to throw things away and try things out without worrying about hurting someone else. Branching in SVN/Perforce is simply not worth the effort, but on Git, it's trivial.
  - brown9-2 15y ago
    But in svn or p4 those commits are visible to everyone else immediately. With git they are only visible when you are ready to make them so - and you can amend or merge them into a single commit or slice them however you want beforehand. Having your own private repo other than what is on the server allows you to experiment and make a lot more mistake without affecting others.
- sixbrx 15y ago
  You can also freely branch and merge between your own private branches, without making everybody else see these numerous branches polluting the file hierarchy of the central repo. More generally, I never liked how to cvs and subversion a branch is basically just a copy at the file level. That mixes version control metadata among the file paths that are themselves being version controlled.
  - gt384u 15y ago
    THIS. I worked at an organization with ~700 branches with names all pretty much meaningless for a single project, when maybe 10 were actually being developed on. Makes it almost impossible to understand the repo.
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.
Codayus 15y ago
Git is very, VERY commonly used in a "centralised" manner, so don't worry about that. Once you're used to git, the overhead of having to commit and push whenever you would have just commited in svn is minimal. Still, it will always exist - so the question is "what do you get in exchange"? There's two major things: First, the two step process lets you perform commits CONSTANTLY on your local repo. Coming from svn, it may take a little bit to figure out why this is good, but trust me, it is. In svn you (typically) are careful about checking in half working code into the central repo. And rightly so; people are (often) relying on the trunk code to be working. You don't want to break the build, right? But anyone who has done non-trivial work with svn will, sooner or later, lose some work that wasn't "ready" to check in. In retrospect, it feels kind of weird to have source control that you aren't supposed to use... Second, everyone knows that git has strong support for branching. But developers used to svn don't always "get" is that git has REALLY strong support for branching. As in, you should be using it. Right now. Constantly. Are you about to start work on a new issue? Branch. Got a new idea on how to solve that problem? Branch. Unsure if you should branch? Branch. Feeling bored? Branch twice. Okay, I'm exaggerating a little, but only a little. You really should be doing everything in branch, because it's very VERY easy to merge, swap branches, pull changes between branches, shelve a branch and start over, stop working on a branch, restart work on a branch, and generally do whatever you want. Again, anyone who has done non-trivial work with svn will have probably learned that branches are a cunning trap for the unwary - you need to unlearn that. :) I'm sure there are teams out there using git in a "truly" decentralised manner, but in my experience the point of git (and any other dvcs) is actually that it makes a centralised workflow much less painful for the individual devs.
InclinedPlane 15y ago
This is like asking "what's the advantage of driving an Audi S5 over a model T, don't they both get you from point A to B?" Git is a far more advanced tool compared to SVN. It will enable you to do things that SVN is not capable of, and it will save you from trouble that would have resulted in a multi-day firedrill in SVN. For example, with Git you can maintain local history on your desktop quite easily. Since there won't ever be conflicts, committing is effortless. But now you have the ability to rollback to a previous state quite easily, far beyond the ctrl-z capabilities of your favorite IDE. Also, in general with Git merging your changes into the central repo ought to be easier than it was previously. If there are conflicts they'll be easier to sort out, for example.
- jeltz 15y ago
  Agreed about conflicts. One of the things that surprised me the most with git, coming from subversion, was how much easier it was to merge code and how there were less conflicts and how they were often much easier to resolve. I tried to do mostly branched development in subversion but gave up on that due to all conflicts.
  - InclinedPlane 15y ago
    One of the downsides of git (and mercurial and others) being evangelized so heavily as next generation distributed version control systems is that some of the more fundamental improvements get passed over. These are world-class version control systems, even discounting their dvcs capabilities. If you do a merge with git/hg vs svn or even perforce or TFS you'll get about as good an experience and a workflow as is possible.
kalid 15y ago
In the basic use case (changes into a central repo), git and svn look similar. Git's power is revealed when you realize how it tracks changes individually -- it's super easy to branch and move changes around. The decentralization isn't just on a team level, it's on a per-developer level. Let's say you have 3 bugs to fix. In SVN you might work on them 1 at a time (start to finish -- hopefully no blockers!), or descend into madness and try to work on all 3 simultaneously. In git, you'd make 3 branches and work on each separately. Oh, a hotfix came along while you're halfway through a bugfix? In SVN, you cringe: do I manually copy my changes somewhere else and revert? Ugh. In git, you just make another branch from your clean master, do the hotfix, and pull that change into your bug branches at your leisure. In svn, this branching is theoretically possible, but not used practically -- they are too cumbersome and manual (you need to track what changes went where, and could accidentally apply them twice). I've written more about it here, if you're interested: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ http://betterexplained.com/articles/intro-to-distributed-ver...
- jeltz 15y ago
  Additionally for working with multiple fixes at the same time git stash -p, git add -p and friends are great tools. I sometimes see a bug when either fixing another bug or implementing a feature. And if that bug is trivial (i.e. it would take less work to fix it right away compared to remembering it) I can fix it right away, and commit it later in a new branch unrelated to the one I was actually working on. With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember.
  - kalid 15y ago
    Totally agree. When first learning git, I got comfortable with git stash: work work, bug comes along, git stash, apply bug to master, git stash apply to get back to my state, work work. Then I started getting comfortable with branches. Git stash is a killer feature that every developer can relate to, and highlights git's power.
  - nupark2 15y ago
latchkey 15y ago
The thing I notice is that you weren't using branches with Subversion. For about 4 years now, I've been doing branch based iterative development. This is a great way for a team of engineers to work together and have a continuous release process. Meaning, you deploy trunk and do development on 'iterative branches' (ie: you have branches called iteration-0001, iteration-0002, iteration-0003, etc...). All works happens on the iteration branches which are then tested and merged to trunk on a regular basis as part of the release process. If you have work that spans more than one iteration, you make a branch off the current iteration. Unfortunately, subversion has a very hard time keeping track of development that way. The reason is that if you (and your co-workers) want to work on another branch off of the iteration branches (so you don't hold up a release), then merging changes from the iteration branches into your branch become a nightmare because merge tracking on your branch has no way to know what is happening on the other branches. If you don't do it right, you can end up with a branch that can never be merged back. The way merge tracking is handled is a central design failure of Subversion. I made a long blog posting about this a while back: http://lookfirst.com/2011/04/subversion-mistake.html http://lookfirst.com/2011/04/subversion-mistake.html Git handles all of this beautifully. So, while today, you might not need the extra functionality of git, it is good to have a tool which can support your needs in the future.
- spc476 15y ago
  The last time I used git in a work environment [1] we named our branches based on the tracking system ID we used. So when I saw a branch labeled US137, I could look that up in the tracking system to see what was being worked on. Our QA team would then pull the developer's assigned branches into a QA repository, do a merge and test. We had no probems [2] with a team of half a dozen programmers across as many time zones (one in Russia) using that model. [1] My current employer uses SVN and I was told, in no uncertain terms, "The use of Git is a fireable offense." The lead developer really hates Git. [2] The problems we did have came from upper management that kept changing their minds about what to work on.
  - JoshTriplett 15y ago
    > [1] My current employer uses SVN and I was told, in no uncertain terms, "The use of Git is a fireable offense." The lead developer really hates Git. Reminds a bit of this quote in LWN from David Woodhouse (a Linux kernel developer at Intel): 'If my corporate overlords told me I had to use my Exchange "messaging" account for external email communication, they would get a quite clear 'no' in response. My response may also contain suggestions that they use certain other objects for purposes for which they were not designed.' More seriously, it sounds like someone who had a bad experience with Git at one point got put in an undeserved position of power in which they got to enforce the results of that bad experience on everyone else.
barend 15y ago
I've come to see the key distinction between git and SVN as: * Old workflow: "commit code" and "share code with team" are jumbled together. * New workflow: "commit code" and "share code with team" are separate actions. This looks so obvious, but coming from years of using SVN, it took me a while to understand the implications. With git I could fix (with commit --amend) those embarrassing "whoops, forgot to add an untracked file" kinds of mistakes. Over time, I found that my local commits became smaller and more frequent because I can reorder and squash them before pushing (or git-svn dcommitting, as most of my clients run SVN). Consider a larger change where you might implement it one way, decide you were on the wrong track, back off a bit and implement it some other. With SVN these false paths are either in the common repository confusing the history, or I'm in a disconnected state for an uncomfortably long time. With git, all these changes are local commits that are ultimately kept out of the main history because I've reordered the change history into something comprehensible. It took me a few months to grok git. Reading an article on the filesystem structure of the repository helped me a great deal.
pkaler 15y ago
You may be doing it "wrong". My old Perforce workflow: code, code, code, code, code, code, code, code, commit My new Git workflow: code, commit, code, commit, code, commit, code, commit, code, commit, code, commit, push It's the difference between single-piece flow and large-batch production in Lean Manufacturing.
- jinushaun 15y ago
  This, and branches. I rarely used branches in svn, but I branch all the time in git locally. If you try to use git like svn, it's pretty frustrating. Seems like a lot of work for no gain. But if you embrace the git philosophy of commit early and often and local feature branches, you'll understand how git got so popular. In svn, I often run into the situation where I'm working on a new feature, want to save what I've done (because it works), but it's not ready to check into the central repo. Then I usually do something that breaks the whole thing locally, but I have no way of undoing that change since nothing has been committed yet. I've seen svn users copy and paste entire directories just to "snapshot" their work. With git and local commits, you don't have this problem. You "save" your progress as you go along by committing it locally and when something breaks, you revert locally. Then when your feature is ready, you push the whole thing to the central repo.
- JoshTriplett 15y ago
  > My new Git workflow: code, commit, code, commit, code, commit, code, commit, code, commit, code, commit, push Likewise, but mine frequently looks like this: branch, code, commit, code, commit, code, commit, rebase -i, rebase branch on master, code, commit, rebase branch on master, merge, push.
- ataggart 15y ago
  Except "commit" means different things between the two examples. From the perspective of the rest of the team, they are both code+, push.
aneth 15y ago
While I'm sure others can address all of the many advantages of git, it's one of those things you don't realize how much you "need" it until you have it, then you take its power for granted until you are stuck using svn. Think iPad, running water, the wheel, a spreadsheet application, or any variety of things.

by j_col 15y ago

jlongster 15y ago

It's saving you because you can freely commit without ever running into a conflict suprisingly. Deal with the merges and conflicts when you want to. Also, it's lot faster to commit. You shouldn't be pushing out every commit -- just commit a lot and when you want others to see it, push it.

j_col 15y ago
I could commit pretty freely using Subversion or Perforce to. As for the faster Git commits, is that just because you are only commiting locally? You still have the overhead of pushing to your central repo. Reading the original article, it seems his reason for switching to Git can be summed up in one word: Github.
- jaggederest 15y ago
  > I could commit pretty freely using Subversion or Perforce to. Pretty freely is not freely. That's like having 'decent' freedom of speech, y'see. Git allows you to commit any time, so fast you won't even notice the pause. > As for the faster Git commits, is that just because you are only commiting locally? You still have the overhead of pushing to your central repo. Yes, it's faster because it only commits locally. You should not push every commit to the central repo, and you should be committing more or less every time you change a file. Git allows you to be far more granular than SVN or perforce did. It also allows you to throw things away and try things out without worrying about hurting someone else. Branching in SVN/Perforce is simply not worth the effort, but on Git, it's trivial.
- brown9-2 15y ago
  But in svn or p4 those commits are visible to everyone else immediately. With git they are only visible when you are ready to make them so - and you can amend or merge them into a single commit or slice them however you want beforehand. Having your own private repo other than what is on the server allows you to experiment and make a lot more mistake without affecting others.
sixbrx 15y ago
You can also freely branch and merge between your own private branches, without making everybody else see these numerous branches polluting the file hierarchy of the central repo. More generally, I never liked how to cvs and subversion a branch is basically just a copy at the file level. That mixes version control metadata among the file paths that are themselves being version controlled.
- gt384u 15y ago
  THIS. I worked at an organization with ~700 branches with names all pretty much meaningless for a single project, when maybe 10 were actually being developed on. Makes it almost impossible to understand the repo.

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.

Codayus 15y ago

Git is very, VERY commonly used in a "centralised" manner, so don't worry about that. Once you're used to git, the overhead of having to commit and push whenever you would have just commited in svn is minimal. Still, it will always exist - so the question is "what do you get in exchange"? There's two major things: First, the two step process lets you perform commits CONSTANTLY on your local repo. Coming from svn, it may take a little bit to figure out why this is good, but trust me, it is. In svn you (typically) are careful about checking in half working code into the central repo. And rightly so; people are (often) relying on the trunk code to be working. You don't want to break the build, right? But anyone who has done non-trivial work with svn will, sooner or later, lose some work that wasn't "ready" to check in. In retrospect, it feels kind of weird to have source control that you aren't supposed to use... Second, everyone knows that git has strong support for branching. But developers used to svn don't always "get" is that git has REALLY strong support for branching. As in, you should be using it. Right now. Constantly. Are you about to start work on a new issue? Branch. Got a new idea on how to solve that problem? Branch. Unsure if you should branch? Branch. Feeling bored? Branch twice. Okay, I'm exaggerating a little, but only a little. You really should be doing everything in branch, because it's very VERY easy to merge, swap branches, pull changes between branches, shelve a branch and start over, stop working on a branch, restart work on a branch, and generally do whatever you want. Again, anyone who has done non-trivial work with svn will have probably learned that branches are a cunning trap for the unwary - you need to unlearn that. :) I'm sure there are teams out there using git in a "truly" decentralised manner, but in my experience the point of git (and any other dvcs) is actually that it makes a centralised workflow much less painful for the individual devs.

InclinedPlane 15y ago

This is like asking "what's the advantage of driving an Audi S5 over a model T, don't they both get you from point A to B?" Git is a far more advanced tool compared to SVN. It will enable you to do things that SVN is not capable of, and it will save you from trouble that would have resulted in a multi-day firedrill in SVN. For example, with Git you can maintain local history on your desktop quite easily. Since there won't ever be conflicts, committing is effortless. But now you have the ability to rollback to a previous state quite easily, far beyond the ctrl-z capabilities of your favorite IDE. Also, in general with Git merging your changes into the central repo ought to be easier than it was previously. If there are conflicts they'll be easier to sort out, for example.

jeltz 15y ago
Agreed about conflicts. One of the things that surprised me the most with git, coming from subversion, was how much easier it was to merge code and how there were less conflicts and how they were often much easier to resolve. I tried to do mostly branched development in subversion but gave up on that due to all conflicts.
- InclinedPlane 15y ago
  One of the downsides of git (and mercurial and others) being evangelized so heavily as next generation distributed version control systems is that some of the more fundamental improvements get passed over. These are world-class version control systems, even discounting their dvcs capabilities. If you do a merge with git/hg vs svn or even perforce or TFS you'll get about as good an experience and a workflow as is possible.

kalid 15y ago

In the basic use case (changes into a central repo), git and svn look similar. Git's power is revealed when you realize how it tracks changes individually -- it's super easy to branch and move changes around. The decentralization isn't just on a team level, it's on a per-developer level. Let's say you have 3 bugs to fix. In SVN you might work on them 1 at a time (start to finish -- hopefully no blockers!), or descend into madness and try to work on all 3 simultaneously. In git, you'd make 3 branches and work on each separately. Oh, a hotfix came along while you're halfway through a bugfix? In SVN, you cringe: do I manually copy my changes somewhere else and revert? Ugh. In git, you just make another branch from your clean master, do the hotfix, and pull that change into your bug branches at your leisure. In svn, this branching is theoretically possible, but not used practically -- they are too cumbersome and manual (you need to track what changes went where, and could accidentally apply them twice). I've written more about it here, if you're interested: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ http://betterexplained.com/articles/intro-to-distributed-ver...

jeltz 15y ago
Additionally for working with multiple fixes at the same time git stash -p, git add -p and friends are great tools. I sometimes see a bug when either fixing another bug or implementing a feature. And if that bug is trivial (i.e. it would take less work to fix it right away compared to remembering it) I can fix it right away, and commit it later in a new branch unrelated to the one I was actually working on. With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember.
- kalid 15y ago
  Totally agree. When first learning git, I got comfortable with git stash: work work, bug comes along, git stash, apply bug to master, git stash apply to get back to my state, work work. Then I started getting comfortable with branches. Git stash is a killer feature that every developer can relate to, and highlights git's power.
- nupark2 15y ago

latchkey 15y ago

The thing I notice is that you weren't using branches with Subversion. For about 4 years now, I've been doing branch based iterative development. This is a great way for a team of engineers to work together and have a continuous release process. Meaning, you deploy trunk and do development on 'iterative branches' (ie: you have branches called iteration-0001, iteration-0002, iteration-0003, etc...). All works happens on the iteration branches which are then tested and merged to trunk on a regular basis as part of the release process. If you have work that spans more than one iteration, you make a branch off the current iteration. Unfortunately, subversion has a very hard time keeping track of development that way. The reason is that if you (and your co-workers) want to work on another branch off of the iteration branches (so you don't hold up a release), then merging changes from the iteration branches into your branch become a nightmare because merge tracking on your branch has no way to know what is happening on the other branches. If you don't do it right, you can end up with a branch that can never be merged back. The way merge tracking is handled is a central design failure of Subversion. I made a long blog posting about this a while back: http://lookfirst.com/2011/04/subversion-mistake.html http://lookfirst.com/2011/04/subversion-mistake.html Git handles all of this beautifully. So, while today, you might not need the extra functionality of git, it is good to have a tool which can support your needs in the future.

spc476 15y ago
The last time I used git in a work environment [1] we named our branches based on the tracking system ID we used. So when I saw a branch labeled US137, I could look that up in the tracking system to see what was being worked on. Our QA team would then pull the developer's assigned branches into a QA repository, do a merge and test. We had no probems [2] with a team of half a dozen programmers across as many time zones (one in Russia) using that model. [1] My current employer uses SVN and I was told, in no uncertain terms, "The use of Git is a fireable offense." The lead developer really hates Git. [2] The problems we did have came from upper management that kept changing their minds about what to work on.
- JoshTriplett 15y ago
  > [1] My current employer uses SVN and I was told, in no uncertain terms, "The use of Git is a fireable offense." The lead developer really hates Git. Reminds a bit of this quote in LWN from David Woodhouse (a Linux kernel developer at Intel): 'If my corporate overlords told me I had to use my Exchange "messaging" account for external email communication, they would get a quite clear 'no' in response. My response may also contain suggestions that they use certain other objects for purposes for which they were not designed.' More seriously, it sounds like someone who had a bad experience with Git at one point got put in an undeserved position of power in which they got to enforce the results of that bad experience on everyone else.

barend 15y ago

I've come to see the key distinction between git and SVN as: * Old workflow: "commit code" and "share code with team" are jumbled together. * New workflow: "commit code" and "share code with team" are separate actions. This looks so obvious, but coming from years of using SVN, it took me a while to understand the implications. With git I could fix (with commit --amend) those embarrassing "whoops, forgot to add an untracked file" kinds of mistakes. Over time, I found that my local commits became smaller and more frequent because I can reorder and squash them before pushing (or git-svn dcommitting, as most of my clients run SVN). Consider a larger change where you might implement it one way, decide you were on the wrong track, back off a bit and implement it some other. With SVN these false paths are either in the common repository confusing the history, or I'm in a disconnected state for an uncomfortably long time. With git, all these changes are local commits that are ultimately kept out of the main history because I've reordered the change history into something comprehensible. It took me a few months to grok git. Reading an article on the filesystem structure of the repository helped me a great deal.

pkaler 15y ago

You may be doing it "wrong". My old Perforce workflow: code, code, code, code, code, code, code, code, commit My new Git workflow: code, commit, code, commit, code, commit, code, commit, code, commit, code, commit, push It's the difference between single-piece flow and large-batch production in Lean Manufacturing.

jinushaun 15y ago
This, and branches. I rarely used branches in svn, but I branch all the time in git locally. If you try to use git like svn, it's pretty frustrating. Seems like a lot of work for no gain. But if you embrace the git philosophy of commit early and often and local feature branches, you'll understand how git got so popular. In svn, I often run into the situation where I'm working on a new feature, want to save what I've done (because it works), but it's not ready to check into the central repo. Then I usually do something that breaks the whole thing locally, but I have no way of undoing that change since nothing has been committed yet. I've seen svn users copy and paste entire directories just to "snapshot" their work. With git and local commits, you don't have this problem. You "save" your progress as you go along by committing it locally and when something breaks, you revert locally. Then when your feature is ready, you push the whole thing to the central repo.
JoshTriplett 15y ago
> My new Git workflow: code, commit, code, commit, code, commit, code, commit, code, commit, code, commit, push Likewise, but mine frequently looks like this: branch, code, commit, code, commit, code, commit, rebase -i, rebase branch on master, code, commit, rebase branch on master, merge, push.
ataggart 15y ago
Except "commit" means different things between the two examples. From the perspective of the rest of the team, they are both code+, push.

aneth 15y ago

While I'm sure others can address all of the many advantages of git, it's one of those things you don't realize how much you "need" it until you have it, then you take its power for granted until you are stuck using svn. Think iPad, running water, the wheel, a spreadsheet application, or any variety of things.