6 ms·

I've been using git (and GitHub) at my day job for a couple years now, and I'm still not sure I'm sold on it over Subversion. In the past, version control was

I've been using git (and GitHub) at my day job for a couple years now, and I'm still not sure I'm sold on it over Subversion. In the past, version control was something that existed but you never had to think about. When you got to a good place, you'd hit the big red Save Button and up your code would go. Once in a blue moon you'd step on somebody's changes and have to do a quick merge. No big deal. Now with Git, version control is part of the workflow. It's never far from your mind. You're creating branches before writing code (versus creating branches three times a year when you needed them). You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you. I'm sure there are times where Git has actually made things easier, but most of the time it's just one extra thing taking up my attention. It's like timesheets for your code. Not a big deal, but ever so slightly insulting that you have to deal with them.

darkFunction 12y ago
> You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you. I'm sure if you were a release manager, or the lead of a sizeable team, or the owner of a busy open source project, you would feel very differently about 'silly' modularised changesets and branching.
- m_eiman 12y ago
  I don't get this "it makes things easier for a select few, so everyone else just has to suffer an over complicated system" thing. We should make the few suffer instead of the masses; optimize to lower global suffering. It should be possible to build a system that exposes different interfaces to different users, shouldn't it?
  - kryptiskt 12y ago
    This guy in the crowd finds it very convenient to be able to commit locally so that you can easily get back to an earlier state of the thing when you fuck up or wants to explore another way to do it. The masses have spoken and they want git.
    - coffeeaddicted 12y ago
      The masses are split with still a slight preference to svn: http://www.ohloh.net/repositories/compare http://www.ohloh.net/repositories/compare (I'm sure there are other statistics out there, but your comment had made me curious and this was the only one I knew of)
      - Zitrax 12y ago
        Would be interesting to compare that to repositories created in the last 2 years or something. It might have quite a different distribution as some old projects probably have kept the vcs they started out with.
  - darkFunction 12y ago
    Well it is. You can make branching as complex or as simple as you want. Where I work the developers are only ever exposed to the feature branch they are working on, which is even created automagically for each Jira ticket from the correct release/integration/dev branch. So for a developer it really couldn't be any simpler.
  - sanderjd 12y ago
    Modular commits with good messages are analogous to well-written code with good documentation - both are not terribly important (though not harmful either!) for individual contributors but absolutely critical for teams and especially those working at the aggregate team level, like the release managers and team leads your parent mentioned.
anko 12y ago
What the heck? I couldn't disagree more. You don't have to create a branch before you write some code. Write the code, and if you think it should go on a different branch, type "git checkout -b 'branchname'". But if you don't want to, you don't have to! work on master for all anyone cares. Branches just help you! IF they are too hard, don't use them. Branches were so problematic in subversion that nobody did them. In git, if you want to, then do it. If you accidently check in something, just "git rm" it. You have this extra staging area. If you are finding there is something problematic with your workflow, take the time to look up how to do it, and you'll find that the fix is a command away. You should never be copying/pasting stuff back into your IDE. If you are, you're doing it wrong. http://gitref.org/ http://gitref.org/ is pretty good if you get stuck.
- sanderjd 12y ago
  It sounds like your parent is working within a team with a defined git workflow that they find too heavy but don't have the final say in defining.
- craigching 12y ago
  I agree with you, and would like to add to it. The parent said git gets in the way ... I couldn't disagree more with that. More than any other version control software, git stays out of my way and my workflow until I need it. Rename a file? No big deal, take care of it before I commit, for now rename it and keep working. Need these changes to go on a branch? As you said, "git checkout -b <branchname>" and BAM! I'm on a branch (most unlike SVN branching). Contrast that with something like perforce (and I know the parent was comparing to SVN) where it intrudes into my workflow whether I want it to or not. p4 edit? pshaw! I have been using the "git p4" module for a few years now in my corporate p4 environment. It ain't native git, but it's better than p4 IMO. EDIT: Come on. If you disagree with me, don't downvote, reply so you can contribute to the conversation. Coward.
- Alupis 12y ago
  The nice thing about git, is there is a ton of possible workflows depending on how much you care, how knowledgeable you are about git, level of effort willing to put forth, etc. I've found my workflow in git has changed over the years... just like my coding style does.
alphadevx 12y ago
> In the past, version control was something that existed but you never had to think about. I think its the complexity of git that forces you to think about it. It's really not that user friendly, in comparison to SVN for example. Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that). The big fallacy for me of distributed version control systems is that we all use them in a centralized way anyway (commit loses value, code does not exist at team level until pushed). It just adds another step to your work flow (code->commit->push vs. just code->commit), but the gain isn't obvious. Another SVN fan unconvinced about git.
- thathonkey 12y ago
  Just curious how much experience to you have using git? Days, weeks, months? Have you worked on a team using it before or just by yourself? These aren't loaded questions.
  - alphadevx 12y ago
    I've been using it full-time for the past 2-3 years, in teams of roughly half a dozen devs. I still use SVN for my part-time open source work out of choice. At this stage I'd say I'm very comfortable with git at the CLI (I only ever use source control tools in CLI mode), but it took me a long time to get there.
- craigching 12y ago
  > Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that). Create some aliases that make it as close as possible or as simple as possible for them. There's no need to force someone to learn the whole tool if they only need a subset.
  - jinushaun 12y ago
    I think the core problem is that git is designed for large fast moving code bases with several contributors. So in the process of teaching a newbie git, you can't help but teach them all complicated use cases that show up in a regular workflow. But you don't have to use git this way. You can use it like SVN where the only difference is the index (push pull)
Walkman 12y ago
Git is not easier, it's better! You can do with git what you can do with svn; just commit, push, pull to a central server, no branching, no merging, no rebasing, and voila, you got the same workflow. Nobody forces you to do any complicated if you feel disturbed by it. A screwdriver is much more simple to use than a drill, but if you have to choose one, which would you build a house with?
erikb 12y ago
I'm a huge fan of Git and I think it improves my coding life drastically. But I completely agree with you that git is not better for every task. You either need a shell (which many modern coding tasks simply don't require at all) or you need a reasonably abstract GUI tool (I only know the GitHub GUI tool to fulfill that requirement, all IDE integration I know off sucks). But even in the case of well designed GUI tools you often do things like "create a feature", "send pull request to main repo", etc. If there is git underneath or any other version aware data storage doesn't really matter. A couchDB might have been a fine choice as well. So the only real use case is when you work in shells anyway and when you require the more complex git capabilities. Therefore I don't think it should be the major, hip tool everybody uses and I hope the world soon realizes this and creates tools for every day usage with an every day amount of power under the hood that can be handled without a mastery in git foo. (After having said that, I want to remind the reader that I myself love, need, want and use git with nearly everything it has to offer, but I had the time, energy and interest to dig deep into it for a long time)
mhw 12y ago
> In the past, version control was something that existed but you never had to think about. I think this statement highlights the fact that there are really two camps of developers when it comes to version control software. The difference between the two is what they consider to be the primary artefact that they are working on. One camp considers the primary artefact to be the source tree that they have in front of them. The other camp thinks that the history of that tree over time, as represented in the version control system, is the most important and valuable thing. Where things get rough is when members of the 'source tree' camp have version control imposed on them, usually by some corporate policy change. For them, the version control system is just like a backup. Commit messages are perceived as valueless as the developer never expects to see them again, so quite often they will be blank. Any change to the workflow that gets between the developer and making a change to their source file is a hindrance. I would not recommend that an organisation with developers who are primarily 'source tree'ers try to adopt git. As the parent says, it requires too much knowledge of the tool, change to workflow, and, above all, commitment to having the git repository represent a detailed history of the development process. For them, a simpler tool the stays out of the way is probably more suitable.
- SideburnsOfDoom 12y ago
  That is a useful distinction. However it is possible to hold a middle view, i.e that while the "current source tree" is most important - it is what you build and deploy, what you are most likely to base future work upon; the history is also an important artefact, and more than just a backup. I like a good code history, but not at the expense of good current code!
- craigching 12y ago
  > change to workflow The only change to my workflow coming from a little bit of SVN and a whole ton of CVS was pull and push. Other than that, you can work exactly as you did in CVS and SVN if you want to. Sure the commands are a bit different, but the workflow can be the same.
  - davidgerard 12y ago
up_and_up 12y ago
> It's like timesheets for your code. Not a big deal, but ever so slightly insulting that you have to deal with them. Honestly, I'm not sure you have realized the true power of git branching. Here is our typical workflow at work: 1. Branch master to topic/feature branch 2. Work on feature branch, push feature branch to remote 3. Push of feature branch to remote triggers a Tddium test run. 4. Deploy feature branch to a staging server for internal review. 5. Make fixes, adjustments to feature branch and push to remote, which triggers more Tddium test builds. 6. Once things are looking good, we pull --rebase master, which pulls down everyone elses changes to master. 7. Rebase the feature branch off of master, resolve any conflicts. 8. Merge feature branch into master and push. Above, branching allowed me to: * Save my own personal branches to a remote repo where they are backed up, * Offload my test suite to a 3rd party, * Allow me to deploy a feature branch to a staging server all without messing with the master branch at all. I can also squash or rename commits on my branch easily and cherry-pick other commits from other branches without worrying about master. I can also VERY EASILY switch to other branches to work on other features and bugfixes as they arise. I normally work on 2-4 diff branches per day. Try doing any of that in SVN and be in for fun ride...
- gcb0 12y ago
  Which does nothing to improve the core problems with your workflow :) Offloading tests to 3rd party will not help you ensure that tests run fast as they should. Working too long on your branch will only make mergers more painful later. We use svn and git, but the workflow is still local fast tests before even branches commits. No personal branches, only features, and update those often because they're not exclusively your silo. And commit/merge to head often. And head is the only place where you get the 2h integration test run. Because otherwise, you'd wait 2h after every branch commit (which we know nobody can do)
  - up_and_up 12y ago
    > Which does nothing to improve the core problems with your workflow :) Not sure what you mean. I state above how it helps my workflow. > Offloading tests to 3rd party will not help you ensure that tests run fast as they should. That's not the main point of CI. The main point is both: as a sanity check for tests pushed to the remote and also to not waste your time and CPUs running tests locally. > Working too long on your branch will only make mergers more painful later. I easily rebase off of master on a daily basis with git, no issues there.
tetha 12y ago
This notion works as long as you have a centralized team working on a single code base and they can coordinate through other means. Once you have different people - and potentially even different access levels - working together, you need to be mindful about version-management, be it svn or git. I have exactly this situation at hand at the moment. We are contributing as much as possible to an open source project. However as buisness goes, we need certain extensions to this project which clearly fall under our NDA, so I can't contribute them back. That's precisely where version-management becomes important, and where real benefits of git kick in. In this case, I can do a bit of trickery by chaining repositories: I have a public repository for our contributions, which can open pull request to up-stream. Behind that, I have an internal repository, which has two read-only remote repositories (upstream, and our public contribution repository to fast-track certain changes). From there, you can do the changes in the right repository and need to obtain the changes through the right remote repositories.

darkFunction 12y ago

> You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you. I'm sure if you were a release manager, or the lead of a sizeable team, or the owner of a busy open source project, you would feel very differently about 'silly' modularised changesets and branching.

m_eiman 12y ago
I don't get this "it makes things easier for a select few, so everyone else just has to suffer an over complicated system" thing. We should make the few suffer instead of the masses; optimize to lower global suffering. It should be possible to build a system that exposes different interfaces to different users, shouldn't it?
- kryptiskt 12y ago
  This guy in the crowd finds it very convenient to be able to commit locally so that you can easily get back to an earlier state of the thing when you fuck up or wants to explore another way to do it. The masses have spoken and they want git.
  - coffeeaddicted 12y ago
    The masses are split with still a slight preference to svn: http://www.ohloh.net/repositories/compare http://www.ohloh.net/repositories/compare (I'm sure there are other statistics out there, but your comment had made me curious and this was the only one I knew of)
    - Zitrax 12y ago
      Would be interesting to compare that to repositories created in the last 2 years or something. It might have quite a different distribution as some old projects probably have kept the vcs they started out with.
- darkFunction 12y ago
  Well it is. You can make branching as complex or as simple as you want. Where I work the developers are only ever exposed to the feature branch they are working on, which is even created automagically for each Jira ticket from the correct release/integration/dev branch. So for a developer it really couldn't be any simpler.
- sanderjd 12y ago
  Modular commits with good messages are analogous to well-written code with good documentation - both are not terribly important (though not harmful either!) for individual contributors but absolutely critical for teams and especially those working at the aggregate team level, like the release managers and team leads your parent mentioned.

anko 12y ago

What the heck? I couldn't disagree more. You don't have to create a branch before you write some code. Write the code, and if you think it should go on a different branch, type "git checkout -b 'branchname'". But if you don't want to, you don't have to! work on master for all anyone cares. Branches just help you! IF they are too hard, don't use them. Branches were so problematic in subversion that nobody did them. In git, if you want to, then do it. If you accidently check in something, just "git rm" it. You have this extra staging area. If you are finding there is something problematic with your workflow, take the time to look up how to do it, and you'll find that the fix is a command away. You should never be copying/pasting stuff back into your IDE. If you are, you're doing it wrong. http://gitref.org/ http://gitref.org/ is pretty good if you get stuck.

sanderjd 12y ago
It sounds like your parent is working within a team with a defined git workflow that they find too heavy but don't have the final say in defining.
craigching 12y ago
I agree with you, and would like to add to it. The parent said git gets in the way ... I couldn't disagree more with that. More than any other version control software, git stays out of my way and my workflow until I need it. Rename a file? No big deal, take care of it before I commit, for now rename it and keep working. Need these changes to go on a branch? As you said, "git checkout -b <branchname>" and BAM! I'm on a branch (most unlike SVN branching). Contrast that with something like perforce (and I know the parent was comparing to SVN) where it intrudes into my workflow whether I want it to or not. p4 edit? pshaw! I have been using the "git p4" module for a few years now in my corporate p4 environment. It ain't native git, but it's better than p4 IMO. EDIT: Come on. If you disagree with me, don't downvote, reply so you can contribute to the conversation. Coward.
Alupis 12y ago
The nice thing about git, is there is a ton of possible workflows depending on how much you care, how knowledgeable you are about git, level of effort willing to put forth, etc. I've found my workflow in git has changed over the years... just like my coding style does.

alphadevx 12y ago

> In the past, version control was something that existed but you never had to think about. I think its the complexity of git that forces you to think about it. It's really not that user friendly, in comparison to SVN for example. Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that). The big fallacy for me of distributed version control systems is that we all use them in a centralized way anyway (commit loses value, code does not exist at team level until pushed). It just adds another step to your work flow (code->commit->push vs. just code->commit), but the gain isn't obvious. Another SVN fan unconvinced about git.

thathonkey 12y ago
Just curious how much experience to you have using git? Days, weeks, months? Have you worked on a team using it before or just by yourself? These aren't loaded questions.
- alphadevx 12y ago
  I've been using it full-time for the past 2-3 years, in teams of roughly half a dozen devs. I still use SVN for my part-time open source work out of choice. At this stage I'd say I'm very comfortable with git at the CLI (I only ever use source control tools in CLI mode), but it took me a long time to get there.
craigching 12y ago
> Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that). Create some aliases that make it as close as possible or as simple as possible for them. There's no need to force someone to learn the whole tool if they only need a subset.
- jinushaun 12y ago
  I think the core problem is that git is designed for large fast moving code bases with several contributors. So in the process of teaching a newbie git, you can't help but teach them all complicated use cases that show up in a regular workflow. But you don't have to use git this way. You can use it like SVN where the only difference is the index (push pull)

Walkman 12y ago

Git is not easier, it's better! You can do with git what you can do with svn; just commit, push, pull to a central server, no branching, no merging, no rebasing, and voila, you got the same workflow. Nobody forces you to do any complicated if you feel disturbed by it. A screwdriver is much more simple to use than a drill, but if you have to choose one, which would you build a house with?

erikb 12y ago

I'm a huge fan of Git and I think it improves my coding life drastically. But I completely agree with you that git is not better for every task. You either need a shell (which many modern coding tasks simply don't require at all) or you need a reasonably abstract GUI tool (I only know the GitHub GUI tool to fulfill that requirement, all IDE integration I know off sucks). But even in the case of well designed GUI tools you often do things like "create a feature", "send pull request to main repo", etc. If there is git underneath or any other version aware data storage doesn't really matter. A couchDB might have been a fine choice as well. So the only real use case is when you work in shells anyway and when you require the more complex git capabilities. Therefore I don't think it should be the major, hip tool everybody uses and I hope the world soon realizes this and creates tools for every day usage with an every day amount of power under the hood that can be handled without a mastery in git foo. (After having said that, I want to remind the reader that I myself love, need, want and use git with nearly everything it has to offer, but I had the time, energy and interest to dig deep into it for a long time)

mhw 12y ago

> In the past, version control was something that existed but you never had to think about. I think this statement highlights the fact that there are really two camps of developers when it comes to version control software. The difference between the two is what they consider to be the primary artefact that they are working on. One camp considers the primary artefact to be the source tree that they have in front of them. The other camp thinks that the history of that tree over time, as represented in the version control system, is the most important and valuable thing. Where things get rough is when members of the 'source tree' camp have version control imposed on them, usually by some corporate policy change. For them, the version control system is just like a backup. Commit messages are perceived as valueless as the developer never expects to see them again, so quite often they will be blank. Any change to the workflow that gets between the developer and making a change to their source file is a hindrance. I would not recommend that an organisation with developers who are primarily 'source tree'ers try to adopt git. As the parent says, it requires too much knowledge of the tool, change to workflow, and, above all, commitment to having the git repository represent a detailed history of the development process. For them, a simpler tool the stays out of the way is probably more suitable.

SideburnsOfDoom 12y ago
That is a useful distinction. However it is possible to hold a middle view, i.e that while the "current source tree" is most important - it is what you build and deploy, what you are most likely to base future work upon; the history is also an important artefact, and more than just a backup. I like a good code history, but not at the expense of good current code!
craigching 12y ago
> change to workflow The only change to my workflow coming from a little bit of SVN and a whole ton of CVS was pull and push. Other than that, you can work exactly as you did in CVS and SVN if you want to. Sure the commands are a bit different, but the workflow can be the same.
- davidgerard 12y ago

up_and_up 12y ago

> It's like timesheets for your code. Not a big deal, but ever so slightly insulting that you have to deal with them. Honestly, I'm not sure you have realized the true power of git branching. Here is our typical workflow at work: 1. Branch master to topic/feature branch 2. Work on feature branch, push feature branch to remote 3. Push of feature branch to remote triggers a Tddium test run. 4. Deploy feature branch to a staging server for internal review. 5. Make fixes, adjustments to feature branch and push to remote, which triggers more Tddium test builds. 6. Once things are looking good, we pull --rebase master, which pulls down everyone elses changes to master. 7. Rebase the feature branch off of master, resolve any conflicts. 8. Merge feature branch into master and push. Above, branching allowed me to: * Save my own personal branches to a remote repo where they are backed up, * Offload my test suite to a 3rd party, * Allow me to deploy a feature branch to a staging server all without messing with the master branch at all. I can also squash or rename commits on my branch easily and cherry-pick other commits from other branches without worrying about master. I can also VERY EASILY switch to other branches to work on other features and bugfixes as they arise. I normally work on 2-4 diff branches per day. Try doing any of that in SVN and be in for fun ride...

gcb0 12y ago
Which does nothing to improve the core problems with your workflow :) Offloading tests to 3rd party will not help you ensure that tests run fast as they should. Working too long on your branch will only make mergers more painful later. We use svn and git, but the workflow is still local fast tests before even branches commits. No personal branches, only features, and update those often because they're not exclusively your silo. And commit/merge to head often. And head is the only place where you get the 2h integration test run. Because otherwise, you'd wait 2h after every branch commit (which we know nobody can do)
- up_and_up 12y ago
  > Which does nothing to improve the core problems with your workflow :) Not sure what you mean. I state above how it helps my workflow. > Offloading tests to 3rd party will not help you ensure that tests run fast as they should. That's not the main point of CI. The main point is both: as a sanity check for tests pushed to the remote and also to not waste your time and CPUs running tests locally. > Working too long on your branch will only make mergers more painful later. I easily rebase off of master on a daily basis with git, no issues there.

tetha 12y ago

This notion works as long as you have a centralized team working on a single code base and they can coordinate through other means. Once you have different people - and potentially even different access levels - working together, you need to be mindful about version-management, be it svn or git. I have exactly this situation at hand at the moment. We are contributing as much as possible to an open source project. However as buisness goes, we need certain extensions to this project which clearly fall under our NDA, so I can't contribute them back. That's precisely where version-management becomes important, and where real benefits of git kick in. In this case, I can do a bit of trickery by chaining repositories: I have a public repository for our contributions, which can open pull request to up-stream. Behind that, I have an internal repository, which has two read-only remote repositories (upstream, and our public contribution repository to fast-track certain changes). From there, you can do the changes in the right repository and need to obtain the changes through the right remote repositories.