3 ms·

Well if I commit my changes ASAP to the main branch, there's much less/zero divergence at any given time. This is not about talking - I and the other teammates

Well if I commit my changes ASAP to the main branch, there's much less/zero divergence at any given time. This is not about talking - I and the other teammates might be perfectly aware of it happening and still - we are agile so their work has to be done immediately, mine too, the problem with feature branches remains. I actually tried to simply have my team commit to the main branch, and it worked out quite well - we never had problems with code divergence. I guess it doesn't work so well for larger teams not working on MVPs, though (we were 5 developers).

Xylakant 4y ago
Every time you have a local working copy, you essentially have a feature branch. Their local modifications and your local modifications can be incompatible - pushing to the same branch only moves the problem to “who pushed first”. At least with separate branches, you can observe their changes and pull them in at a suitable time.
- WHATDOESIT 4y ago
  My aforementioned MVP team solved this issue with commiting/pushing and pulling frequently - and a tiny little bit of communication about what we do during the daily standups. We never had too much problems after we got the hang of it. The problem with feature branches is that if there are more than 2 people working on the same place in the code base, it's very hard to synchronize it all without having a common branch, even if all the people are communicating 24/7.
- gocartStatue 4y ago
  You have a short-lived local branch tracking remote main branch, not a feature branch. It works if you `pull --rebase` and never force-push (which is trivial to enforce in the origin repo). That DOES require working in very small increments which is good unless maybe when you're doing highly experimental work that you may discard. In this case a branch might actually be a great idea.
  - Xylakant 4y ago
    You can do exactly the same with a feature branch on the remote side. This is not a replacement for actually communicating around what work you do.
    - WHATDOESIT 4y ago
      Have you tried synchronizing three disparate feature branches this way? I don't think it's really possible. We had a very bad experience trying to do that. The thing is, I want my developers to code, not talk all the time about what/where they would like to code and that the others have to wait until they're finished or suck up the merge conflicts if there's no time. Some communication is always necessary - but this solution with feature branches requires constant communication and still, the developers would rather wait that try to synchronize this way.
      - JimmieMcnulty 4y ago
        What? It’s trivial to keep these branches in sync… The more you comment, the more it’s clear you work with a bunch of coders who want to “go dark”, and there are a ton of problems with that. Don’t go dark.
        WHATDOESIT 4y ago
        Nobody wanted to go dark :-D each of us was an unpaid co-founder. Going dark looks very different from what was happening there - each of these guys just wanted to ship code so we make money, ASAP. Well it wasn't trivial at that stage of our development. It became much more trivial once we and the market were happy with our product-market fit and at that point we indeed started with feature branches again. Now I'm working at a consultancy and since there's much more time for everything, we are doing feature branches during our MVP development too. But there's a stark difference in velocity this current team and the team I told you about achieved.
        JimmieMcnulty 4y ago

Xylakant 4y ago

Every time you have a local working copy, you essentially have a feature branch. Their local modifications and your local modifications can be incompatible - pushing to the same branch only moves the problem to “who pushed first”. At least with separate branches, you can observe their changes and pull them in at a suitable time.

WHATDOESIT 4y ago
My aforementioned MVP team solved this issue with commiting/pushing and pulling frequently - and a tiny little bit of communication about what we do during the daily standups. We never had too much problems after we got the hang of it. The problem with feature branches is that if there are more than 2 people working on the same place in the code base, it's very hard to synchronize it all without having a common branch, even if all the people are communicating 24/7.
gocartStatue 4y ago
You have a short-lived local branch tracking remote main branch, not a feature branch. It works if you `pull --rebase` and never force-push (which is trivial to enforce in the origin repo). That DOES require working in very small increments which is good unless maybe when you're doing highly experimental work that you may discard. In this case a branch might actually be a great idea.
- Xylakant 4y ago
  You can do exactly the same with a feature branch on the remote side. This is not a replacement for actually communicating around what work you do.
  - WHATDOESIT 4y ago
    Have you tried synchronizing three disparate feature branches this way? I don't think it's really possible. We had a very bad experience trying to do that. The thing is, I want my developers to code, not talk all the time about what/where they would like to code and that the others have to wait until they're finished or suck up the merge conflicts if there's no time. Some communication is always necessary - but this solution with feature branches requires constant communication and still, the developers would rather wait that try to synchronize this way.
    - JimmieMcnulty 4y ago
      What? It’s trivial to keep these branches in sync… The more you comment, the more it’s clear you work with a bunch of coders who want to “go dark”, and there are a ton of problems with that. Don’t go dark.
      - WHATDOESIT 4y ago
        Nobody wanted to go dark :-D each of us was an unpaid co-founder. Going dark looks very different from what was happening there - each of these guys just wanted to ship code so we make money, ASAP. Well it wasn't trivial at that stage of our development. It became much more trivial once we and the market were happy with our product-market fit and at that point we indeed started with feature branches again. Now I'm working at a consultancy and since there's much more time for everything, we are doing feature branches during our MVP development too. But there's a stark difference in velocity this current team and the team I told you about achieved.
        JimmieMcnulty 4y ago