4 ms·

Nope, it encourages merging in your own playground, incrementally. You can (and arguably should) still merge mainline into your branch with some regularity, say

Nope, it encourages merging in your own playground, incrementally. You can (and arguably should) still merge mainline into your branch with some regularity, say once a day. With the issue you're talking about, that's why we have staging environments. If you're going to release A and then B, you should be staging A, and then staging A+B. It's true that if they had ZERO idea on what the other were doing, they could step on each other's toes. But it will get caught before release. And hopefully there's enough communication to at least have a vague idea of who's working on the same parts of the code as you. If you're designing things that span large parts of the codebase without consulting or warning teammates, you have bigger problems. Without distinct feature branches, you end up in abysmal horror situations where you push something, realize you have a bug in production, but can't roll it back without rolling N other features back. Then you start hacking in code to turn the feature off temporarily, etc, which rapidly turns into a mess.

DEinspanjer 13y ago
So in this model, what is the right way to merge mainline into your branch? Is it "git pull upstream mainline" while in your branch or something else?
- mscuwa 13y ago
  Create A+B integration branch, then merge in both directions, A -> A+B then A+B -> A (to pick up changes from B). Integration branch can be tested and merged to master later instead of individual branches A and B. It's not that complex as it sounds.
  - DEinspanjer 13y ago
    Probably too late to get another reply, but I'll ask anyway.. I'm thinking about the scenario where you create a branch to do some dev work. It takes a week or so, during which, other commits are happening on master. Probably at multiple points during your week of dev work, you are going to want to pull in updates from master to make sure you don't hit conflicts or run into issues that weren't found until the day you try to merge your final work. It sounds like you are saying that every time you want to update, you'd create a new integration branch of your work + master and then switch to that for further work until you are finally ready to commit to master? That feels a bit unwieldy..
lars 13y ago
Branch A and B can merge in from mainline every hour, but you wont catch problems with A+B until either is merged _into_ master. Yes, you can catch the problem in staging, but you might have caught it before that if you had merged earlier. > Without distinct feature branches, you end up in abysmal horror situations where you push something, realize you have a bug in production, but can't roll it back without rolling N other features back. I don't think having a dev branch in an unshippable state is an abysmal horror situation. And even if you use feature branches for everything, that does not mean you can necessarily roll back the commits easily.
prawks 13y ago
As someone new to large-scale DCVS usage, what do the remote repositories look like in a scenario like this? Do the developers of feature A and B push their respective feature branches to a repo in the staging environment where they are merged in some local integration branch there? Logistically, who does the merging? Is it this integration branch that is then merged into mainline?

DEinspanjer 13y ago

So in this model, what is the right way to merge mainline into your branch? Is it "git pull upstream mainline" while in your branch or something else?

mscuwa 13y ago
Create A+B integration branch, then merge in both directions, A -> A+B then A+B -> A (to pick up changes from B). Integration branch can be tested and merged to master later instead of individual branches A and B. It's not that complex as it sounds.
- DEinspanjer 13y ago
  Probably too late to get another reply, but I'll ask anyway.. I'm thinking about the scenario where you create a branch to do some dev work. It takes a week or so, during which, other commits are happening on master. Probably at multiple points during your week of dev work, you are going to want to pull in updates from master to make sure you don't hit conflicts or run into issues that weren't found until the day you try to merge your final work. It sounds like you are saying that every time you want to update, you'd create a new integration branch of your work + master and then switch to that for further work until you are finally ready to commit to master? That feels a bit unwieldy..

lars 13y ago

Branch A and B can merge in from mainline every hour, but you wont catch problems with A+B until either is merged _into_ master. Yes, you can catch the problem in staging, but you might have caught it before that if you had merged earlier. > Without distinct feature branches, you end up in abysmal horror situations where you push something, realize you have a bug in production, but can't roll it back without rolling N other features back. I don't think having a dev branch in an unshippable state is an abysmal horror situation. And even if you use feature branches for everything, that does not mean you can necessarily roll back the commits easily.

prawks 13y ago

As someone new to large-scale DCVS usage, what do the remote repositories look like in a scenario like this? Do the developers of feature A and B push their respective feature branches to a repo in the staging environment where they are merged in some local integration branch there? Logistically, who does the merging? Is it this integration branch that is then merged into mainline?