4 ms·

Git does not solve the issue of accidental complexity introduced by branching. Since we are exchanging arbitrary statements: If you need branches outside the re

Git does not solve the issue of accidental complexity introduced by branching. Since we are exchanging arbitrary statements: If you need branches outside the realm of libraries with multiple supported versions, you're doing something very, very wrong. "Feature branching is a poor man's modular architecture". And I'm pretty confident about my git-fu. Agree on the testing, though, unless you're doing horrible generated cruds it is usually faster to write tests than not.

JimmieMcnulty 4y ago
Git completely removes the complexity introduced by branching, as it takes care of merging the branch for you? It honestly sounds like you don’t know what a branch is, since you’re talking about libraries and multiple supported branches, so I very much doubt your “git-fu”. It sounds like you’re in the “merge conflicts are hard” camp, which is a camp of ignorance.
- gocartStatue 4y ago
  I’m in a „merge conflicts are a waste” camp. I don’t need multiple parallel versions of software (unless it’s a library following semver). I need to hear a single good reason for not applying changes incrementally to main branch multiple times a day.
  - JimmieMcnulty 4y ago
    Coworkers. Also you’re pushing code into this main branch from… where? Another main branch. That’s literally how git works, you’re just removing any oversight and collaboration opportunities by insisting on calling this branch you’ve created locally “main” as well. Code reviews are awesome, and not doing them is a fantastic way to ruin your team’s ability to support work they didn’t themselves write.
    - gocartStatue 4y ago
      Does it have to be post-coding, pre-merge code review? The difference lies in size of the diff and the manner of introducing changes. Other developers have your changes instantly. This is core of the discipline called „continuous integration”. I’ve been in multiple teams doing mandatory, pre-merge, double code reviews and getting crappy results. The longer someone kept their precious feature branch isolated, the worse. And keeping branches „up to date” only solves a small part of the problem with long lived branches.
      - JimmieMcnulty 4y ago
        Yeah, but nobody here is suggesting long lived branches, nothing about a feature branch requires that it exist for a “long time”. Your local “main” branch that you’re developing a feature against is a “feature branch” you just aren’t calling it that. But even if it did, regularly remerging main back into it (or rebasing) does solve like 90% of the issues being described here, and further comes with a whole host of other benefits.

JimmieMcnulty 4y ago

Git completely removes the complexity introduced by branching, as it takes care of merging the branch for you? It honestly sounds like you don’t know what a branch is, since you’re talking about libraries and multiple supported branches, so I very much doubt your “git-fu”. It sounds like you’re in the “merge conflicts are hard” camp, which is a camp of ignorance.

gocartStatue 4y ago
I’m in a „merge conflicts are a waste” camp. I don’t need multiple parallel versions of software (unless it’s a library following semver). I need to hear a single good reason for not applying changes incrementally to main branch multiple times a day.
- JimmieMcnulty 4y ago
  Coworkers. Also you’re pushing code into this main branch from… where? Another main branch. That’s literally how git works, you’re just removing any oversight and collaboration opportunities by insisting on calling this branch you’ve created locally “main” as well. Code reviews are awesome, and not doing them is a fantastic way to ruin your team’s ability to support work they didn’t themselves write.
  - gocartStatue 4y ago
    Does it have to be post-coding, pre-merge code review? The difference lies in size of the diff and the manner of introducing changes. Other developers have your changes instantly. This is core of the discipline called „continuous integration”. I’ve been in multiple teams doing mandatory, pre-merge, double code reviews and getting crappy results. The longer someone kept their precious feature branch isolated, the worse. And keeping branches „up to date” only solves a small part of the problem with long lived branches.
    - JimmieMcnulty 4y ago
      Yeah, but nobody here is suggesting long lived branches, nothing about a feature branch requires that it exist for a “long time”. Your local “main” branch that you’re developing a feature against is a “feature branch” you just aren’t calling it that. But even if it did, regularly remerging main back into it (or rebasing) does solve like 90% of the issues being described here, and further comes with a whole host of other benefits.