> 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.

Thank you! Your post explains what I've been seeing at the day job.

We switched from a Subversion-like proprietary VCS to git about six months ago.

We needed to because the proprietary thing was a stupid waste of money (it was basically equivalent to Subversion in capabilities), and because its ability to do the sort of branching we found ourselves in need of was severely limited. So we switched to git.

We've had more than a little culture shock since then - and basically it's because we work in source-tree mode, and history is something you delve into only when you have to. In fact, when we moved to the new system (git on Github) we didn't even port history - we started the Github repos with a historyless copy of the source, and left the old stuff in the old system should anyone need to look at it. Github basically serves the role of the central repo in the old system.

We would never go back - git centred on Github is a vast improvement on the old system - but it's a bit too fully-featured for what we want from it, and has the problem you describe where we have to think too much about the tool's view of things.

> 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.

Only if you keep a clear picture in your head of the tool's view of your repo - in a manner that CVS/Svn does not require you to. Otherwise you are pretty much certain to shoot yourself in the foot, repeatedly. Source: watching our devs do precisely this.

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!

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/ is pretty good if you get stuck.

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.

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.

I've just started using git recently and have completely fallen in love with its power and flexibility.

But as someone just starting out, I can relate to how demanding git can _seem_ to a beginner. Say I have some refactoring ideas floating around in my head. I could either begin accommodating for these changes in git (namely branching, perhaps also chunking my edits into commits) or start coding and go back and handle commit isolation and branching later.

For me it can seem like git is getting in the way if I select the former method, and that the latter is just messy and cumbersome. But the more and more time I invest into the tool, both my efficiency and the cleanliness of the code base increases. Persevering through the higher learning curve (which exists probably due to a minimal (bad?) interface wrapping a set of concepts that can best be understood visually à la Dwarf Fortress) appears to be a worthwhile investment.

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.

> 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.

> 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.

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)

If you're that concerned about "commit + push" vs. just "commit" then you might want to just alias "commit" to "commit + push" :).

Anyway, I think I get what you're saying wrt. less experienced users, but I found that with the proper explanation it wasn't actually that hard to get the point across. When explaining it to my coworkers, I've always tended towards focusing on the human factors. Namely things such as: "Don't you wish you could have taken that commit back?" (rebasing), "Everyone has a backup of the whole history"[1], "Hey look, if you mess up a merge, you can just say 'git reflog' and figure out where you were before everything got messed up", etc. If people can see the advantage in terms of their professional goals they are usually very willing to learn even relatively arcane tools such as git :).

[1] I know that's a white lie, but...

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.

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.

> 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...

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)

> 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.

rebase is not the same as avoiding merge problems.

what does it help you if you and other dev have their, often rebased or not, branches for a long time? the first one will be fine, second will have merge hell.

honestly, you are only comfortable with that setup because you probably work alone on a small team.

edit: and dont get me wrong, if that is the case, you are using the right tool for the job. i would love to be able to not rely on regular atomic commits in my huge dysfunctional group.

(Not the OP, obviously.)

> rebase is not the same as avoiding merge problems.

Yes it is. The point is this: Everybody rebases against "what is to become our next release" on a continual (daily if not more frequent) basis. If you have acceptable levels of unit testing and integration testing on your feature branches there's usually no problem with early (that is, way before the sprint ends) merging of feature branches to master. If your team is really paranoid and all your team's feature branches tend to pile up until the last day of the sprint[1], you could forcibly (via process) stagger your feature merges so that they're always at least 1 day apart to catch any bad interactions between features.

[1] This is indicative of other problems to do with process/management, so take the next bit of advice with a grain of salt.

> 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.

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?

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.

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.

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.

The masses are split with still a slight preference to svn: 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)

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.

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?

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)

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.