Isn't the git history in the picture above nice to work with? There are probably many problems in that repository, but one of them is most definite...
For further actions, you may consider blocking this person and/or reporting abuse
Hi Jean-Paul, you make a good case but you can still use feature toggles even with feature branches and also all devs working on the master branch means that the build might be broken for a long time in some cases.
The biggest drawback though (which is mostly the reason GitHub and the others encourage feature branching) is having to deal with the increasing async nature of our work. More and more companies are distributed and some are even async.
It's doable to work on the master branch if all devs can talk to each other in a room or in a chat room in real time. "Sorry, I broke the build, I'm going to fix it" but what if you have multiple set of developers working on different timezones that may or may not overlap?
The build could be broken for hours if someone is unavailable or asleep.
This already can happen with important bugs that need to be fixed ASAP, adding the load of fixing a feature written by someone else because it impedes the work of those devs that are "online" seems an unnecessary burden.
It'll lead to commit messages like "commenting out feature X because I have no idea how it works but it's breaking the build". :D
I think it's a valid idea, I'm just not sure it works best with fully distributed and remote teams.
Hi Rhymes,
First of all thanks for reading!
You make a valid point that "all devs working on the master branch" might no apply to all setups. You could be remote, async or even have newcomers in the team who need more structure and guidance before starting up and being up to the standard.
The way to mitigate that is to use branches, but not feature branches a.k.a "long lived branches". You would create a branch per logical piece of code that you want to merge in. Then merging goes through a continuous integration tool that lets the code in only if it does not break the main branch. You could also open a PR and have this go through a code review if needed.
The main idea remains: you diverge from the master branch for a short period of time: say 1 day max and then sync back in. This way you eliminate big merge issues and avoid the "unpredictable release syndrome".
Cheers,
JP
Agreed! Short lived branches are what I interpret feature branches for. For a feature, as small as possible. I once worked in a place where every dev had their own long lived branch and multiple feature branches and it was a bit of a nightmare as you wrote about :D
Yeah when I think of feature branches I think of something that's around for a week or two at most. Committing stuff to trunk is hard because you can't make small, incremental commits that might be a bit sloppy. Having a feature branch can make saving your state less stressful because you don't have to worry about others seeing your commit that says "oops I broke this now it's good".
Yep, also confused here somewhat, always thought of "feature branches" as being around for anywhere from minutes to days at worst. GitHub has no mechanism for code-reviewing individual commits, so I don't know how you'd do reviews on the main branch anyways.
(For longer-term branches, I had thought the term was "project branch", which is a collection of feature branches.)
Thanks for the comments!
I have updated the title and added this to the introduction: "For the sake of clarity: this article assumes a feature branch will carry the whole feature you are developing and is a so called 'long-lived' feature branch that will last 1 week or more. It's not a "no branches at all" mantra."
You seem to be referring to people who use feature branches incorrectly.
Some notes:
Monster branches are discouraged in all pipelines. But they are not a reason to avoid feature branches.
Doing code reviews after a branch has been merged seems odd. What if the review says the entire approach is wrong, or requires other significant changes?
Your approach muddies the master branch, and increases the instability of it.
Feature toggles are also not incompatible with feature branches. These are orthogonal concepts.
I've updated the title and intro to specify I am talking about "feature branches" as "long lived feature branches". By long lived I mean more than a day or two. Usually when I see "feature branches" used, "feature" is a feature of the project or the product. It is rarely developed "shortly" and sometimes require a week or more to get in. Working on a branch like this is not efficient in my opinion.
I don't see how feature toggles can be used with feature branches though. If your feature is only on the branch and this branch is not deployed to production, how do you use feature toggles to turn your feature on and off?
I don't think I'd limit it to a day or two, sometimes a small feature can take longer. It's somehow related to the size of code, and certainly, something taking weeks, has likely gone off into la-la land.
Feature toggles can still be used on immature features that need real-world testing. You don't get to toggle features which aren't in the master branch. I've used these before. Part of the feature includes a toggle mechanism. These should be accompanied with a clear plan of when it becomes the default and the old system is deprecated.
However, if you follow the advice of regularly merging main into the feature branches, you should be able to selectively merge several branches to get a working version. I've done this on several projects as well. Sort of a mix-and-match of branches instead of the feature toggles. This definitely requires regular main-to-branch merging though, otherwise you'll hit all sorts of errors.
There is something that always bothered me with feature branching and seeing that you seem pretty convinced of them maybe you can solve this for me.
Developer A and Developer B branch out of master at the start of the sprint to do their job and both pull and merge from master frequently but no one is pushing to master so, how do they know they are not breaking each other stuff?
Keep the branches short-lived and avoid working on the same parts of the code. Avoiding the same parts of the code applies to whatever branching strategy you are using.
There's rarely a need for two people to work on the same bits of code in the same period. This can usually be recognized during triage and planning.
In the unusual case where two people are working on the same code, it should be for the same feature, in which case, they can share a branch. And they should probably sit close to each other in the office and communicate.
The moment one of them feels the need to pull from the other's branch, the warning sirens should go off. It sounds like a monster branch is growing.
Looks like you worked with feature branches incorrectly perhaps. I prefer them (at least for small distributed teams) 100%. If nothing else than for the reviews. In my experience if everybody commits it becomes a huge mess soon, and the "master" don't work most of the time...
With trunk based devel you need a new look on how to do reviews effectively, and I don't know yet good and available tools for small teams to do that. (I am aware of big companies overgrowing feature branches and having good tooling for trunk based.) Suggestions?
Hi, thanks for the article.
In my opinion, there is a huge advantage to the feature branches - and that's the visibility in the history. There are reasons to look in the history (like a year ago) of the cvs, when trying to explain why something is implemented that way or the other. And then, if you see the work on a branch, you know the whole context.
Also, if you're worried about the changes on the trunk that might affect the feature branch work, just pull the develop branch and rebase on top of it - as frequently, as you're suggesting to merge. I'm of the opinion that on your branch you can modify that history however you want.
Moreover, if you think you're able to commit every time unfinished work to the develop - maybe the scope of the "features" is just too large. What about splitting it up, and then calling these chunks a feature?
Thanks again,
Krzysiek.
If you're not using something like GitHub where this is no notion of pull requests then I completely agree that this is a valid point that need addressing. If you're using GH however, you have the complete history of the branch in a Pull Request.
I suggest taking a look at slides.com/lirantal/effective-git-... to see if you get convinced with trunk based development :)
I don't quite understand what's going on here. Ideally, work in small chunks on feature branches that have short lives. Rebase early and often. Never submit a pull request that hasn't been rebased against master. Then rebase (and squash) it again on approval. There shouldn't be a significant span of time where you're off ignoring what's going on in the rest of the project.
Granted, I've been guilty of monster submissions that add 1000s of lines and need a week to review. But that should be a wild exception, and I kept on top of rebasing and conflict resolution every day.
IMO, the problem with committing straight to master and then reviewing it and then cleaning up after is that it causes a mess. While it's on a feature branch, you can edit history, squash, revise, amend - everything's hypothetical until you finally land it. But, once it's landed, it's real and everyone has to deal with it - including the after-hours breakages to build & test systems that might come up.
"work in small chunks on feature branches that have short lives"
Agree on some part: I have updated the title and article to mention short lived branches are OK.
Disagree on the other :): as the name suggests, "feature branch" are supposed to carry a whole feature. Unless you are making a very small change or fixing a bug, this is probably work for 1 week or more. Working on your own that long is a risk.
"But, once it's landed, it's real and everyone has to deal with it"
Agree. And this is true whether you write your code in 15 minutes push and go on vacations, or spend 3 months revising and amending all over until it's perfect. And the more you wait, the bigger the risk. While if you think about "what are the contact points between the existing code and my new code" in a feature toggles kind of way, you will build an abstraction layer around your feature that will make it easier to integrate every step of the way.
What do you think?
Great writing and appreciate you advocating for TBD.
I've been running that for several years and have been able to successfully introduce it on several engineering teams I was leading.
If you fancy some slides on the subject to introduce this to new teams I have given this one on several meetups and conferences: slides.com/lirantal/effective-git-...
Long lived branches miss the lessons which led to continuous integration. The rebase workflow provides a means to do continuous integration on long lived branches as long as all work isn't long lived at the same time. It also puts insentive on the branch maintainer to find a point to merge in their work early.
Stop, Let's Talk Before You Flag that Feature
Jesse Phillips
Usually people comment because they disagree. In this case I'm posting because this is heterodoxy while also the way I feel about feature branches. The whole idea of a version control system is to allow the team to work together. This means being synchronized in terms of the code base. Having people run off on their own branches and mark stories as complete based on a branch creates a problem with knowing what is actually included in the main code base. I understand why Git and feature branches might make sense in highly distributed or open source teams where features are highly atomic and developers work more independently, but in co-located teams working closely with one another feature branches lead to endless discussions about which features are actually merged, and conflicts over merges. Evolution means small regular change. Branching is essentially a fork which will require healing.
Marking an issue/story/req complete in a branch is also a bad workflow. They should not be marked as complete until they are merged into the master branch, or whatever the developing branch is.
GitHub even has this feature automated. If you mark branches fixing issues, those issues will be closed once they are merged.
I think the title is a bit misleading. With Trunk Based Development you still have branches but they are short-lived and intended to be integrated very quickly into the main line of development, as opposed to the traditional feature branches that usual span for weeks or months until a feature is "complete".
"I think the title is a bit misleading" Indeed. I've updated the title and added mentions of short lived branches where appropriate. Hopefully it's clearer now.
At least the original title brought in a lot of interesting discussion :)
the idea of feature toggles never clicked with me for some reason. maybe because I'd have to test that my code doesn't work unless I enable it. it's trivial if I change the old behavior with a shiny new one but how do I test that my buggy new feature is completely unavailable and cannot be accidentally called by something else?
Feature flags (or toggles) are essential for continuous deployment and quick delivery because they allow you to manage things like canary releases and the ability to "test in production" ( 🤯). Obviously you should actual test and choose a well designed feature flags solution but at the end of the day and for the sake of simplicity you can think of them like a code branch:
You could also argue how those would be tested and while that's not always easy it's definitely doable. Another way to think of feature flags is that they are merely configuration items.
Interesting article, I just think the 1 or 2 day limit is a bit tight. I love to get back to master as soon as possible, but at the same time I don't think uncompleted code should be merged to master. Feature toggles can help with that, but only if it is a new pathway. If you are refactoring or modifying existing code it may not be possible to feature toggle it.
We run a simple git flow with a master branch and a branch for each work item or bug we work on. The code merges to master as soon as the work item is code completed and dev tested. The intention is that no work item should take longer than a week.
You're right about any branch that sits around for too long is never going to make it to master.
As a fan of continuous integration I am obviously not a fan of feature branches, and thus agree with your article
Dave Farley wrote a similar article on this:
davefarley.net/?p=247
You mentioned "The Goal" and WIP as reasons to go to the Trunk based. If you haven't already, check out "The Phoenix Project", it draws a lot from "The Goal" based on a DevOps environment.
Thanks Josh. Downloaded on my Kindle and on to start reading it tonight!
Awesome I will be interested to hear the perspective of reading "The Goal" first as I am reading them the opposite way. 👍