3 ms·

> when we say CI, what CI really meant was actually integrate your code regularly. Code living on separate branches is, by definition, not integrated. When I w

> when we say CI, what CI really meant was actually integrate your code regularly. Code living on separate branches is, by definition, not integrated. When I work on a long lived (say, a week or two) branch, I just rebase it on main every morning or some times several times per day. It always contains 100% of everyone elses code. But their code contains 0% of my commits yet. Because that's the point of the branch. That none of it is visible to anyone else, until I deem it ready to. The point is that when I merge it, it looks like an atomic change on main, which takes it from one working state (100% passing tests and so on) to another working state. And the only way to ensure that is to make the validation take place IN my branch. If I'm eager to "publish" my work, I can do that. I can make multiple branches with just one or two commits each on monday and tuesday with new functionality behind some feature flag. And then the final friday commit is basically just flipping the feature flag. But it doesn't change the fact that I do want to make sure main stays healthy so I still want to gate the commits. I don't think there is a pattern of development that works everywhere, and whether one thinks that feature branches is an overhead I think will vary. People who are used to a project taking 3 months and having multiple builds per day, perhaps having their tests run in seconds via a commit hook, will think that the overhead of a PR is massive. But if validation builds/tests take multiple hours anyway then the overhead of making branches isn't really going to have an impact on productivity.

BiteCode_dev 3y ago
You can do that with squash-merge.
- mattpallissard 3y ago
  But with squash you lose all of the individual commits.
  - BiteCode_dev 3y ago
    That's a pros, not a con. Once something is merged, intermediary steps to get that new thing are no longer interesting. In fact, most rebase workflows squash anyway. In the rare case you have 3 steps in that PR of 23 commits you want to keep, squash it in 3 pieces and merge them.
    - JoeAltmaier 3y ago
      The catch is, does it have to be functional at every step? It may be hard to find checkpoints inside a PR where the changes still produce a useful (testable) product without breaking anything. If it doesn't have to be testable in three pieces, then why break it down? For clarity when reviewing the changes perhaps.
      - alkonaut 3y ago
        The best reason to have it broken up is for posterity to be able to annotate the changes. If there is a 100 line refactor followed by the 10 line actual functional change, then it's a blessing to be able to look at that in isolation when something has gone wrong with it 5 or 10 years later.
    - mattpallissard 3y ago
      Keeping the commit as the unit of change allows you to orchestrate with a single PR. The commit is the change, the PR is the go button. > In the rare case you have 3 steps in that PR of 23 commits I'd have 3 commits in this case. It's not rare at all when you have code, charts, terrform, and scripts housed in a single repo. But even if you're just touching code some changes make sense to go out at the same time. Personally, I feel that the use case for squash is when there are many WIP commits. Those could be avoided with the use of --amend, or --fixup, or cherry picking without a commit, etc.
benjaminwootton 3y ago
I tend to view it like this too. I'm in control of the new feature on my branch, it's my responsibility to rebase to avoid a nasty merge, I can then run automated tests and I can push my work at a point where I'm ready in a set of logical and atomic commits. I agree I think both have their pro's and con's. You can do trunk based development badly where your mainline is always broken, and you can do feature branching badly where you sit on a branch for months and then break the world when you merge. I have not seen a lot of success with pull requests. Usually people just seem to say LGTM, then the original developer merges. That could just be the company I keep. Either way, I don't see them as a significant benefit of feature branches. I'm not sure of the terminology as I've stepped away from development, but we used to work by the whole team working on a release branch, then merging to main at stable points. Maybe that gives the best of both worlds in terms of stable trunk and keeping continuous integration?
- SkyPuncher 3y ago
  This is how my team does it. If we have a large feature with multiple people pushing code, we’ll create a “feature branch” that we then branch against. We run our PR flow into the “feature branch” then merge the feature branch into main when ready. As part of smaller features, people rebase from main and work upstream changes back into the feature branch. Worst case, we spend and hour near the end of the project on a “merge party” where we work out all of the conflicts.
swinglock 3y ago
> It always contains 100% of everyone elses code. It contains no one else's code since everyone works on a branch. This is only holds if a single team uses a brach. That doesn't scale.
- dspillett 3y ago
  > It contains no one else's code since everyone works on a branch. 100% of everyone else's code that has made it to main. If you need to coordinate more closely (i.e. different people working on related changes, which is likely to be common) then the branch doesn't have to be local and just for you, it can be shared, perhaps with individuals having their own local copy of that for quick check-ins¹ without publishing to others until ready². Whether this scales manageably will depend on the project and your team dynamics. -- [1] to save work state before experimental changes, or just to have an off-machine last-known-good copy (assuming your “local” repo is covered by off-machine backups or is not actually local) [2] though this indirection adds extra overhead – someone needs to rebase that from main then everyone may need to rebase to bring local copies in line
  - mannykannot 3y ago
    I feel it is likely to scale better than the alternatives, as it is a recursively hierarchical model of a recursively hierarchical problem. It would break if people are committing broken things, but then you have a different and more fundamental problem.
- mlyle 3y ago
  No one commits as they write each line of code. There's always code in flux and you are not integrating with everyone else every minute. Branches vs. on-trunk misses the mark, IMO: the question is what's your practices like for how frequently changes get integrated. There's multiple dimensions of freedom in how you do things. Branching is a nice tool to have. Avoiding long-lived feature branches is best (particularly with a big subset of the team working in them). (But, dang, sometimes you need these abilities, too, so having a workflow that supports them well is good).
- 3y ago
softwaredoug 3y ago
I would add code living on separate repos is also not integrated :) I've had such headaches working across repos and having a "microrepo" organization scheme without thought to how these things are tested against each other.
- jitl 3y ago
  At Airbnb in 2014 we hand internal NPM and Ruby Gem ecosystems published to internal package servers and integrated via version bumps and installs… so annoying to make a PR on foolib, test it a bunch, publish a alpha version” so I can install it in barlib* and test it there, and then need to make 2 PRs and do an official publish in between them.
  - softwaredoug 3y ago
    Not to mention every repo might have a different dev experience, different ways to test, different everything. Just multiplies dev ex pain times number of repos.
haspok 3y ago
I used to be a solid believer in merging and not rebasing, but then I had the chance of working on a project where rebase + fast forward only merges were the norm (with some additional rules), and I have to admit, it worked really well. I don't even remember any serious merge conflicts, and there were some really long lived branches there!
- mattpallissard 3y ago
  I usually can sell rebase+FF to a team by using rev-parse to revert a range of commits immediately without conflict. It's a little more effort to get in the habit of, but it pays dividends.

BiteCode_dev 3y ago

You can do that with squash-merge.

mattpallissard 3y ago
But with squash you lose all of the individual commits.
- BiteCode_dev 3y ago
  That's a pros, not a con. Once something is merged, intermediary steps to get that new thing are no longer interesting. In fact, most rebase workflows squash anyway. In the rare case you have 3 steps in that PR of 23 commits you want to keep, squash it in 3 pieces and merge them.
  - JoeAltmaier 3y ago
    The catch is, does it have to be functional at every step? It may be hard to find checkpoints inside a PR where the changes still produce a useful (testable) product without breaking anything. If it doesn't have to be testable in three pieces, then why break it down? For clarity when reviewing the changes perhaps.
    - alkonaut 3y ago
      The best reason to have it broken up is for posterity to be able to annotate the changes. If there is a 100 line refactor followed by the 10 line actual functional change, then it's a blessing to be able to look at that in isolation when something has gone wrong with it 5 or 10 years later.
  - mattpallissard 3y ago
    Keeping the commit as the unit of change allows you to orchestrate with a single PR. The commit is the change, the PR is the go button. > In the rare case you have 3 steps in that PR of 23 commits I'd have 3 commits in this case. It's not rare at all when you have code, charts, terrform, and scripts housed in a single repo. But even if you're just touching code some changes make sense to go out at the same time. Personally, I feel that the use case for squash is when there are many WIP commits. Those could be avoided with the use of --amend, or --fixup, or cherry picking without a commit, etc.

benjaminwootton 3y ago

I tend to view it like this too. I'm in control of the new feature on my branch, it's my responsibility to rebase to avoid a nasty merge, I can then run automated tests and I can push my work at a point where I'm ready in a set of logical and atomic commits. I agree I think both have their pro's and con's. You can do trunk based development badly where your mainline is always broken, and you can do feature branching badly where you sit on a branch for months and then break the world when you merge. I have not seen a lot of success with pull requests. Usually people just seem to say LGTM, then the original developer merges. That could just be the company I keep. Either way, I don't see them as a significant benefit of feature branches. I'm not sure of the terminology as I've stepped away from development, but we used to work by the whole team working on a release branch, then merging to main at stable points. Maybe that gives the best of both worlds in terms of stable trunk and keeping continuous integration?

SkyPuncher 3y ago
This is how my team does it. If we have a large feature with multiple people pushing code, we’ll create a “feature branch” that we then branch against. We run our PR flow into the “feature branch” then merge the feature branch into main when ready. As part of smaller features, people rebase from main and work upstream changes back into the feature branch. Worst case, we spend and hour near the end of the project on a “merge party” where we work out all of the conflicts.

swinglock 3y ago

> It always contains 100% of everyone elses code. It contains no one else's code since everyone works on a branch. This is only holds if a single team uses a brach. That doesn't scale.

dspillett 3y ago
> It contains no one else's code since everyone works on a branch. 100% of everyone else's code that has made it to main. If you need to coordinate more closely (i.e. different people working on related changes, which is likely to be common) then the branch doesn't have to be local and just for you, it can be shared, perhaps with individuals having their own local copy of that for quick check-ins¹ without publishing to others until ready². Whether this scales manageably will depend on the project and your team dynamics. -- [1] to save work state before experimental changes, or just to have an off-machine last-known-good copy (assuming your “local” repo is covered by off-machine backups or is not actually local) [2] though this indirection adds extra overhead – someone needs to rebase that from main then everyone may need to rebase to bring local copies in line
- mannykannot 3y ago
  I feel it is likely to scale better than the alternatives, as it is a recursively hierarchical model of a recursively hierarchical problem. It would break if people are committing broken things, but then you have a different and more fundamental problem.
mlyle 3y ago
No one commits as they write each line of code. There's always code in flux and you are not integrating with everyone else every minute. Branches vs. on-trunk misses the mark, IMO: the question is what's your practices like for how frequently changes get integrated. There's multiple dimensions of freedom in how you do things. Branching is a nice tool to have. Avoiding long-lived feature branches is best (particularly with a big subset of the team working in them). (But, dang, sometimes you need these abilities, too, so having a workflow that supports them well is good).
3y ago

softwaredoug 3y ago

I would add code living on separate repos is also not integrated :) I've had such headaches working across repos and having a "microrepo" organization scheme without thought to how these things are tested against each other.

jitl 3y ago
At Airbnb in 2014 we hand internal NPM and Ruby Gem ecosystems published to internal package servers and integrated via version bumps and installs… so annoying to make a PR on foolib, test it a bunch, publish a alpha version” so I can install it in barlib* and test it there, and then need to make 2 PRs and do an official publish in between them.
- softwaredoug 3y ago
  Not to mention every repo might have a different dev experience, different ways to test, different everything. Just multiplies dev ex pain times number of repos.

haspok 3y ago

I used to be a solid believer in merging and not rebasing, but then I had the chance of working on a project where rebase + fast forward only merges were the norm (with some additional rules), and I have to admit, it worked really well. I don't even remember any serious merge conflicts, and there were some really long lived branches there!

mattpallissard 3y ago
I usually can sell rebase+FF to a team by using rev-parse to revert a range of commits immediately without conflict. It's a little more effort to get in the habit of, but it pays dividends.