What version controls don't solve: Semantic Conflict

Let's imagine I'm looking at that calculateBill method and realize that as well as calculating the bill, it also sends off accounting entries to the accounting system. I don't like the side effect, so I pull it out into a separate notifyAccounting method.

Before:

    calculateBill: BillEntries -> Writer (AccountingSystem) Bill
    ...Jed's code:...
    produceBillEntries >>= calculateBill >>= billProcessor

    calculateBill: BillEntries -> Bill
    notifyAccounting: BillEntries -> (Writer AccountingSystem) ()
    ...Jed's code:...
    produceBillEntries >>= calculateBill >>= billProcessor

Like anything else, feature branches can be abused, and require some discipline on the part of the developer to use correctly.

On git.git every feature is developed on its own branch. However, the maintainer integrates all the features into a single branch for testing and to prevent these sorts of semantic issues from creeping up. It's really only an issue where the feature branch is allowed to diverge too far from the main branch.

As a developer maintaining your own feature branch, there are generally two good practices to follow:

- Regularly integrate the main branch with your feature branch, review what's coming in from main, and test. Having a feature branch does not relieve you of being aware of what else is going on in the code base. Note that you'll generally do this on a throw-away branch, as you don't want to clutter your feature branch with test merges.

- Rebase your feature branch as needed if the changes in main invalidate any of your work so far. As part of rebasing, you'll have to account for those changes.

You can have a long-lived feature branch, the important thing is not to go into a cave with it. You need to keep it up-to-date wrt to mainline development.

For a shared feature branch, rebasing is a bit harder (but not impossible), so instead you will typically merge the main branch into your feature branch as needed. It is important to do these merges only when necessary if you wish to maintain a relatively clean development history, something that is important if you later need to track down the source of a bug or backout the feature.

Yes, static typing fixes problems with changing function signatures but that's only the first step of the way. The next step is to start thinking about and defining modules (files, classes, whatever) in semantic terms.

I haven't heard it discussed in a few years but the discussions around the Liskov substitution principle and Liskov/Wing semantic typing highlights the difficulties of adding semantics to everyday software development practices.