10 ms·

This is written as if git doesn’t exist, and Agile were never invented. If branching/merging is giving you this much trouble, you’re doing something very, very

This is written as if git doesn’t exist, and Agile were never invented. If branching/merging is giving you this much trouble, you’re doing something very, very wrong. Pause, actually learn git, then resume. Also, testing is so easy, if you’re doubling your dev time writing tests, that’s another thing you need to dedicate time to for learning, because it should add maybe 10% more if you’re competent.

WHATDOESIT 4y ago
How does learning Git solve the problem that the other team members changed the code so much I have to rewrite half my work again? Happens especially in agile environments - waterfall is planned upfront so usually you don't change what you already did.
- Xylakant 4y ago
  How does any tool help if your colleagues don’t talk to you? Or you don’t talk to your colleagues?
  - WHATDOESIT 4y ago
    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.
- JimmieMcnulty 4y ago
  I’ve been using git for nearly 15 years and not more than a half dozen times has resolving a merge conflict taken me more than 15 minutes. This just isn’t a real problem. Try working more incrementally, or try working with colleagues who don’t rewrite large swaths of code without coordinating with their team. You have a people problem, not a tool problem.
  - WHATDOESIT 4y ago
    We're in agreement - what I said is basically that learning to use the tool better doesn't help, and what helped was to do exactly what you said, make smaller increments and integrate them frequently. Ad not rewriting large swaths - that's more of a product management issue and was outside our control. It wasn't all bad too - we were simply searching for that product-market fit.
    - JimmieMcnulty 4y ago
      Learning to use the tool absolutely does help, because it alters your workflow to fix your glaring developer experience issues. Your team is suffering badly from a lack of even a baseline understanding of how to develop software as a group, and learning even the most basic usage of git would substantially alleviate that issue.
      - WHATDOESIT 4y ago
        Our team was suffering from a somewhat unusual business situation, but that's about it. I don't think any of us could've learned something truly new about Git (well except me, maybe - but I was not writing too much code anyways). When your business changes wildly every 2-3 months for a year (and sometimes few times a month too), it's hard to not change the code base a lot. Our place was not to change this situation - our place was to learn to deal with it, which we did satisfyingly.
        JimmieMcnulty 4y ago
        You’re literally doing feature branches, you’re just doing it worse by not changing the names of the branch as you have it locally (so you can’t share or store your work anywhere but on your machine), but you don’t know enough about git to speak intelligently with others to accurately describe your team’s workflow. Also I guarantee I’ve used git branches in more dynamic situations than what you’ve described here and it caused absolutely zero issues.
gocartStatue 4y ago
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.

WHATDOESIT 4y ago

How does learning Git solve the problem that the other team members changed the code so much I have to rewrite half my work again? Happens especially in agile environments - waterfall is planned upfront so usually you don't change what you already did.

Xylakant 4y ago
How does any tool help if your colleagues don’t talk to you? Or you don’t talk to your colleagues?
- WHATDOESIT 4y ago
  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.
JimmieMcnulty 4y ago
I’ve been using git for nearly 15 years and not more than a half dozen times has resolving a merge conflict taken me more than 15 minutes. This just isn’t a real problem. Try working more incrementally, or try working with colleagues who don’t rewrite large swaths of code without coordinating with their team. You have a people problem, not a tool problem.
- WHATDOESIT 4y ago
  We're in agreement - what I said is basically that learning to use the tool better doesn't help, and what helped was to do exactly what you said, make smaller increments and integrate them frequently. Ad not rewriting large swaths - that's more of a product management issue and was outside our control. It wasn't all bad too - we were simply searching for that product-market fit.
  - JimmieMcnulty 4y ago
    Learning to use the tool absolutely does help, because it alters your workflow to fix your glaring developer experience issues. Your team is suffering badly from a lack of even a baseline understanding of how to develop software as a group, and learning even the most basic usage of git would substantially alleviate that issue.
    - WHATDOESIT 4y ago
      Our team was suffering from a somewhat unusual business situation, but that's about it. I don't think any of us could've learned something truly new about Git (well except me, maybe - but I was not writing too much code anyways). When your business changes wildly every 2-3 months for a year (and sometimes few times a month too), it's hard to not change the code base a lot. Our place was not to change this situation - our place was to learn to deal with it, which we did satisfyingly.
      - JimmieMcnulty 4y ago
        You’re literally doing feature branches, you’re just doing it worse by not changing the names of the branch as you have it locally (so you can’t share or store your work anywhere but on your machine), but you don’t know enough about git to speak intelligently with others to accurately describe your team’s workflow. Also I guarantee I’ve used git branches in more dynamic situations than what you’ve described here and it caused absolutely zero issues.

gocartStatue 4y ago

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.