4 ms·

what's the idea behind no feature branches?

jcoder 13y ago
If I understand GP, it's the idea that when your work on a feature branch is complete, you use rebase to base that branch on the current tip of the branch you are integrating to, e.g., "master", so the result does not reveal the presence of a branch.
- sanderjd 13y ago
  If I understand the poster you're replying to, he understood that, but doesn't understand why you would want that. I'm in the same boat - why are people willfully throwing away useful history?
  - andrewflnr 13y ago
    Define "useful history". ;) There's history in the sense of "log of everything that happened" but also in the sense of a nice record of decisions that were made, documentation essentially. I'm guessing "no feature branches" aims more for the latter. Personally, I'm not sure why we shouldn't have both.
    - SoftwareMaven 13y ago
      Both would be nice. I generally restructure commits before pushing them to master in order to make them easier to read, which is nice for others. However, I think about the code in the order I built it, especially when I need to remember why I did something. Unfortunately, that information gets lost if I forget. On the whole, I think restructuring is good (I haven't always felt this way), but something is lost in the process.
    - turtlepower 13y ago
      In this case I'd like to be able to revert the merge.
    - sanderjd 13y ago
      Feature branches, merge commits, and small (possibly broken!) commits are all better documentation of the process of developing a feature than big "cleaned up" commits.
  - erso 13y ago
    There's a simple concept at work here: origin wins. Whatever is on origin at the moment of you wanting to merge your code is what your code has to work against. When you use a rebase strategy you're allowed the opportunity to make sure your commits actually work on top of what's on origin, and fix merge issues with those commits as they happened. So you rebase, run into a conflict, fix the conflict, run your tests, make sure everything's green, and continue the rebase. When you do the same thing with a merge strategy what happens is you end up fixing the conflicts as part of the merge, and your fixes are hidden in the merge commit. This means your commits prior to the merge commit are broken. They didn't take into account the work that was on origin at the time, and thus they are useless without considering the conflicts that were resolved during the merge. The history you describe is not useful unless it's green and could be applied to origin without conflict. The only way to ensure this, both before and after your commits end up on origin is to do so via a rebase strategy.
    - stfsbrb 13y ago
      Thank you for this. I cannot believe how many people are glossing over the fact that commits which have to be fixed up in a merge are probably broken. Rebasing is not a way of hiding this, it is a way of _going back and fixing it_.
    - sanderjd 13y ago
      Thanks for the well reasoned response! Your points are all reasonable, and I understand the pragmatism in wanting only fully-green commits to be on origin. I just think merge commits for logical chunks of work are more important. I read history to understand developer intention and process more than I bisect history to find problems. Those conflicted commits aren't broken, they represent the best effort at the time the changes were made and merely need to be merged together with the world as it is now.
      - erso 13y ago
        I'm not sure I understand. If I'm making a change to some code and someone else makes a different change to it and pushes their change to origin before me, I do a rebase and see that they made the change, fix my commit (which is broken at that point in time), resolving the merge conflict, and continue on. Instead of seeing some changes that have no basis in reality because they were fixed as part of resolving the conflict when doing the merge, you see only their changes applied on top of the correct state of the world, which gives you a clearer idea of what changes they made. You can still get logical chunks of work with a rebase strategy: you simply rebase on top of the remote and then do a non-fast forward merge, via merge --no-ff.
manojlds 13y ago
No feature branches as in NO feature branches and use feature flags / toggles instead - http://martinfowler.com/bliki/FeatureToggle.html http://martinfowler.com/bliki/FeatureToggle.html
- mh- 13y ago
  Feature branches and feature flags are orthogonal. I have no idea how toggles could negate the need for isolated development branches on an 'important' codebase with multiple contributors working on the same areas of concern.
  - benjiweber 13y ago
    It is certainly possible to avoid feature branches with multiple contributors working on the same areas. We've even been pretty successful performing major refactorings to substantial codebases in this way. The key is to do continuous integration properly - i.e. actually integrate your changes with the rest of the team several times a day. We actually deploy to production several times of day. This requires you to break down changes into very small steps that can be completed, tested, and deployed in an hour or so. Each small change is far less likely to break something, or cause performance degradation. If it does, then you know exactly what caused it without painful debugging. Each small change is unlikely to cause significant merge pain for the rest of the team. This requires you to have excellent automated testing and rapid <5min deploys. There are also tools like branch by abstraction and feature toggles which can help but are only tools. The key is how you work as a team. Feature branches are another way of working. They may be the only way of working in many cases (e.g. distributed team of sporadic contributors). Feature branches are almost the opposite of continuous integration. By definition changes on the branch are not integrated.
draebek 13y ago
Perhaps http://paulhammant.com/2013/04/05/what-is-trunk-based-development/ http://paulhammant.com/2013/04/05/what-is-trunk-based-develo... ?
ajross 13y ago
There are "feature branches", and there are "patch sets with four patches and three merge commits that are there just because the submitter did a bunch of pulls while working on it." If you're dealing with a large code base with many submitters, you have to demand that individual submissions apply cleanly. That is isomorphic to demanding that they be rebased.
- jcrites 13y ago
  I am personally a proponent of rebasing, but I'm reading through the recent Hacker News threads to get a sense of the arguments on both sides. > If you're dealing with a large code base with many submitters, you have to demand that individual submissions apply cleanly. That is isomorphic to demanding that they be rebased. To play devil's advocate for the merge perspective: wouldn't this also be achieved if the commit author had merged master into his branch first before submitting? It will apply cleanly because conflicts were fixed during the merge, rather than because it was rebased.
dmead 13y ago
hi dustin!

If I understand GP, it's the idea that when your work on a feature branch is complete, you use rebase to base that branch on the current tip of the branch you are integrating to, e.g., "master", so the result does not reveal the presence of a branch.

sanderjd 13y ago
If I understand the poster you're replying to, he understood that, but doesn't understand why you would want that. I'm in the same boat - why are people willfully throwing away useful history?
- andrewflnr 13y ago
  Define "useful history". ;) There's history in the sense of "log of everything that happened" but also in the sense of a nice record of decisions that were made, documentation essentially. I'm guessing "no feature branches" aims more for the latter. Personally, I'm not sure why we shouldn't have both.
  - SoftwareMaven 13y ago
    Both would be nice. I generally restructure commits before pushing them to master in order to make them easier to read, which is nice for others. However, I think about the code in the order I built it, especially when I need to remember why I did something. Unfortunately, that information gets lost if I forget. On the whole, I think restructuring is good (I haven't always felt this way), but something is lost in the process.
  - turtlepower 13y ago
    In this case I'd like to be able to revert the merge.
  - sanderjd 13y ago
    Feature branches, merge commits, and small (possibly broken!) commits are all better documentation of the process of developing a feature than big "cleaned up" commits.
- erso 13y ago
  There's a simple concept at work here: origin wins. Whatever is on origin at the moment of you wanting to merge your code is what your code has to work against. When you use a rebase strategy you're allowed the opportunity to make sure your commits actually work on top of what's on origin, and fix merge issues with those commits as they happened. So you rebase, run into a conflict, fix the conflict, run your tests, make sure everything's green, and continue the rebase. When you do the same thing with a merge strategy what happens is you end up fixing the conflicts as part of the merge, and your fixes are hidden in the merge commit. This means your commits prior to the merge commit are broken. They didn't take into account the work that was on origin at the time, and thus they are useless without considering the conflicts that were resolved during the merge. The history you describe is not useful unless it's green and could be applied to origin without conflict. The only way to ensure this, both before and after your commits end up on origin is to do so via a rebase strategy.
  - stfsbrb 13y ago
    Thank you for this. I cannot believe how many people are glossing over the fact that commits which have to be fixed up in a merge are probably broken. Rebasing is not a way of hiding this, it is a way of _going back and fixing it_.
  - sanderjd 13y ago
    Thanks for the well reasoned response! Your points are all reasonable, and I understand the pragmatism in wanting only fully-green commits to be on origin. I just think merge commits for logical chunks of work are more important. I read history to understand developer intention and process more than I bisect history to find problems. Those conflicted commits aren't broken, they represent the best effort at the time the changes were made and merely need to be merged together with the world as it is now.
    - erso 13y ago
      I'm not sure I understand. If I'm making a change to some code and someone else makes a different change to it and pushes their change to origin before me, I do a rebase and see that they made the change, fix my commit (which is broken at that point in time), resolving the merge conflict, and continue on. Instead of seeing some changes that have no basis in reality because they were fixed as part of resolving the conflict when doing the merge, you see only their changes applied on top of the correct state of the world, which gives you a clearer idea of what changes they made. You can still get logical chunks of work with a rebase strategy: you simply rebase on top of the remote and then do a non-fast forward merge, via merge --no-ff.

manojlds 13y ago

No feature branches as in NO feature branches and use feature flags / toggles instead - http://martinfowler.com/bliki/FeatureToggle.html http://martinfowler.com/bliki/FeatureToggle.html

mh- 13y ago
Feature branches and feature flags are orthogonal. I have no idea how toggles could negate the need for isolated development branches on an 'important' codebase with multiple contributors working on the same areas of concern.
- benjiweber 13y ago
  It is certainly possible to avoid feature branches with multiple contributors working on the same areas. We've even been pretty successful performing major refactorings to substantial codebases in this way. The key is to do continuous integration properly - i.e. actually integrate your changes with the rest of the team several times a day. We actually deploy to production several times of day. This requires you to break down changes into very small steps that can be completed, tested, and deployed in an hour or so. Each small change is far less likely to break something, or cause performance degradation. If it does, then you know exactly what caused it without painful debugging. Each small change is unlikely to cause significant merge pain for the rest of the team. This requires you to have excellent automated testing and rapid <5min deploys. There are also tools like branch by abstraction and feature toggles which can help but are only tools. The key is how you work as a team. Feature branches are another way of working. They may be the only way of working in many cases (e.g. distributed team of sporadic contributors). Feature branches are almost the opposite of continuous integration. By definition changes on the branch are not integrated.

draebek 13y ago

Perhaps http://paulhammant.com/2013/04/05/what-is-trunk-based-development/ http://paulhammant.com/2013/04/05/what-is-trunk-based-develo... ?

ajross 13y ago

There are "feature branches", and there are "patch sets with four patches and three merge commits that are there just because the submitter did a bunch of pulls while working on it." If you're dealing with a large code base with many submitters, you have to demand that individual submissions apply cleanly. That is isomorphic to demanding that they be rebased.

jcrites 13y ago
I am personally a proponent of rebasing, but I'm reading through the recent Hacker News threads to get a sense of the arguments on both sides. > If you're dealing with a large code base with many submitters, you have to demand that individual submissions apply cleanly. That is isomorphic to demanding that they be rebased. To play devil's advocate for the merge perspective: wouldn't this also be achieved if the commit author had merged master into his branch first before submitting? It will apply cleanly because conflicts were fixed during the merge, rather than because it was rebased.

dmead 13y ago

hi dustin!