6 ms·

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 e

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.
        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
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.

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.
        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

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.