DCVS is good because you can have tracked local changes. Sometimes you are doing a larger change to the software that takes a while and may require some thought, without stacking up hundreds of minor changes sitting in the source folder uncomitted that get applied simultaneously (a la CVS and SVN) and merges happen into that working folder, with no reversability.

You could make the same argument all the way down to requiring that every single line changed is committed at the instant of writing (otherwise they are hiding their code!).

Without tools like Git and Mercurial, people are still doing exactly the same behaviour, just it isn't being source controlled.

Something about this seems orthogonal to me. There's nothing about dvcs itself that implies a lack of fluidity in a codebase, is there?

In a rough attempt to get down to first principles, CI means you need to be able to deploy a codebase at anytime. Feature development means that codebase needs to be ever-changing. Successful deployment means the codebase needs to be at a level of guaranteed quality.

This means that the quality of a "change" needs to be guaranteed to some level before it is merged to the deployment branch.

So right there, that implies the need for "changes" to be developed and quality-checked somewhere other than on the deployment branch.

I think that takes us pretty inexorably to the practice of branching the codebase, developing there, quality-checking there, and also merging from the deployment branch into the feature branch as the deployment branch changes.

So what's left is qualifying what is meant by "change". Is it one feature? A story? A functionality layer? That can be harder to decide on. Agile says it should be a ui-focused story, but sometimes stories are epics (like a simple form submission that somehow implies several SOA services be set up to make it work). So I think that means we can still do functional dependency analysis and shrink stories down to smaller functional steps, sometimes.

The key is to keep stories/features small enough so that they aren't in progress for weeks at a time. When you're working on a feature and then are faced with a massive merge from the deployment branch, that's where things get messed up.

" Dave Farley (co-author of ‘Continuous Delivery’) describes Continuous Integration as the process of automatically creating a potential release candidate after every commit. Are feature branches going to help you do that? "

I think so, if you build a feature outside of the main branch, test it fully and prepare it correctly, the commit to the main branch will be a potential release candidate. You can't say that if you are integrating a potentially broken feature into the main branch everyday.

I've never seen a git crew work in isolation before. If two teams or people are working on two different modules that need to work together they are still integrating between themselves on a regular basis. It's just that those changes do not get pushed up to main until they are finished.

The issue is that the C in CI is a convenient fiction. Someone on your team is always going to be changing the code, which means that they will have it, at some point, in a state that fails validation. Requiring that they get it to a point where it's fully passing is fine, but in many cases that just means a longer time before checkins.

DVCSes, on the other hand, bring to the surface and keep in the record that the code is always branched to some degree. It's not that it's incompatible, it's that it's giving more granular information than the CI process can work with or needs.

I strongly disagree with this whole notion, I think in fact that the opposite is true.

With Git you can make sure that you merge when your story is actually done, with Subversion you need to worry about other's changes if you commit all the time.

With feature branches you only have to worry about integration into the mainline once, when your task is complete, which makes continuous integration far easier than with the SVN model.

If we would need to call a VCS anti-agile, I think that would actually be SVN, which makes continuos delivery a lot harder.

Git and Mercurial make CI harder. CI is an important part of the discipline needed to make Agile work. (CI is an important part of making anything work). You can still do CI with Git and Mercurial. (If I can, anyone can). But you need to fight the tools (a little bit). Fortunately, Git is super-flexible, and you can make it do (almost) anything.

I strongly agree with the fundamental point that the author is making.

However, there are nuances. A lot of this depends on the type of development that you are doing.

For example, most of my day-to-day work is done in very small increments. Minor bug-fixes, incremental classifier performance improvements, parameter changes, and so on. Only rarely will I work on a feature that is so significant in its' impact that the work-in-progress causes the branch to spend several days in a broken / non-working state. I also work in fairly small teams, so the rate of pushes to Gerrit is quite low: only around a dozen pushes per day or so. This means that integration is pretty easy, and that our CI server gives us value & helps with our quality gating. We can follow a single-branch development path with little to no pain, and because both our software and the division of labour in the team are fairly well organised, conflicts very very seldom occur when merging (even when using suboptimal tools to perform the merges).

This state of affairs probably does not hold for all developers, but it holds for me, and for most of the people that I work with. As a result, we can happily work without feature branches (most of the time), and lean on the CI process to keep ourselves in sync & to measure the performance of our classifiers & other algorithms.

Now, don't get me wrong, I think that Git is great. I am the nominated Git expert in my team, and spend a lot of time helping other team members navigate the nuances of using Git with Gerrit, but for most people it is yet another tool to learn in an already over-complex development environment. Git gives us the flexibility to do what we need to in the environment that we have; but it is anything but effortless and transparent, which is what it really needs to be.

Software development is about developing software. Making systems that work. Not wrangling branches in Git.

My ideal tool would be the bastard son of Git and a real-time collaborative editor. My unit tests should be able to report when my local working copy is in a good state. Likewise, my unit tests should be able to report whether a merge or rebase has succeeded or failed. Why can I not then fully automate the process of integrating my work with that of my colleagues? Indeed, my work should be integrated & shared whenever the following two conditions are met: 1) My unit tests pass on my local working copy, and 2) My unit tests pass on the fully integrated copy. These are the same criteria that I would use when doing the process manually ... so why do it manually? Why not automate it? Triggered by every save, the resulting process would create the appearance of an almost-real-time collaborative working environment, opening up the possibility for new forms of close collaboration and team-working that are simply not possible with current tools. A source file would be a shared document that updates almost in real time. (If it is only comments that are being edited, then there is no reason why the updating could not actually be in real time). This means that you could discuss a change with a colleague, IRC-style, in the comments of a source document, and make the change in the source file at the same time, keeping a record not only of the logic change, but also of the reasoning that led to it. (OK, this might cause too much noise, but with comment-folding, that might not matter too much).

Having said all of that, branches are still useful, as are commit messages, so we would still want something like Git to keep a record of significant changes, and to isolate incompatible works-in-progress in separate branches; but there is no reason why we cannot separate out the "integration" use case and the "collaboration" use case from the "version control" and "record keeping" use cases.

We use gitflow and it works well for us. We run tests before integrating. git isn't anti-agile at all. I don't understand the article.