5 ms·

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 i

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.
    - WHATDOESIT 4y ago
      Nah, we really were not doing feature branches. That would require us to branch out and then merge the branch once the feature is complete - that's what we did initially. Since that didn't work out for us, we committed and pushed basically any non-breaking piece of code, regardless of whether the feature was (ever) finished. A single feature could've been anywhere between 1-20 days of work (let's say 5 days average), but we committed - and pushed to main - roughly every few hours, so none of that "only on your machine" stuff you're talking about. I'm glad that your preferred branching strategy works out well for you.
      - JimmieMcnulty 4y ago
        My brother in Christ what is it you think you’re doing when you clone a repo?
        WHATDOESIT 4y ago
        Not feature branches :-) especially since each of us kept care to have their local copy up-to-date. It's hard to reuse others' code (from unfinished features) otherwise. Seems like by your definition there's no way to not do feature branches. A little weird take, IMHO - I know it as a very specific strategy that you have to consciously perform e.g. by naming your branches correctly in sync with your issue tracking system, by not merging until you're done with that ticket, etc - not something that happens automatically just by cloning. https://sillevl.gitbooks.io/git/content/collaboration/workflows/feature-branch/ https://sillevl.gitbooks.io/git/content/collaboration/workfl...
        JimmieMcnulty 4y ago
        Your local copy is a feature branch, as you are developing features on a branch other than the branch you've designated as the "primary" branch (your "main" is a branch off of the main repo's "main"). There is nothing whatsoever that requires a feature branch be long lived or named anything in particular. This is what I mean when I say you don't understand the technology you're using. What you have linked is a "flow" that uses branching, and isn't relevant to this discussion.

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.
  - WHATDOESIT 4y ago
    Nah, we really were not doing feature branches. That would require us to branch out and then merge the branch once the feature is complete - that's what we did initially. Since that didn't work out for us, we committed and pushed basically any non-breaking piece of code, regardless of whether the feature was (ever) finished. A single feature could've been anywhere between 1-20 days of work (let's say 5 days average), but we committed - and pushed to main - roughly every few hours, so none of that "only on your machine" stuff you're talking about. I'm glad that your preferred branching strategy works out well for you.
    - JimmieMcnulty 4y ago
      My brother in Christ what is it you think you’re doing when you clone a repo?
      - WHATDOESIT 4y ago
        Not feature branches :-) especially since each of us kept care to have their local copy up-to-date. It's hard to reuse others' code (from unfinished features) otherwise. Seems like by your definition there's no way to not do feature branches. A little weird take, IMHO - I know it as a very specific strategy that you have to consciously perform e.g. by naming your branches correctly in sync with your issue tracking system, by not merging until you're done with that ticket, etc - not something that happens automatically just by cloning. https://sillevl.gitbooks.io/git/content/collaboration/workflows/feature-branch/ https://sillevl.gitbooks.io/git/content/collaboration/workfl...
        JimmieMcnulty 4y ago
        Your local copy is a feature branch, as you are developing features on a branch other than the branch you've designated as the "primary" branch (your "main" is a branch off of the main repo's "main"). There is nothing whatsoever that requires a feature branch be long lived or named anything in particular. This is what I mean when I say you don't understand the technology you're using. What you have linked is a "flow" that uses branching, and isn't relevant to this discussion.