6 ms·

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

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.
        WHATDOESIT 4y ago
        Well, terms have meanings and it's nice to keep it, makes discussion easier. So yeah sure, we were doing 2 hours-long 1%-of-a-feature branches.
        JimmieMcnulty 4y ago
        It does make discussion easier, which is why your improper use of the term caused such confusion here, and illustrates my larger point; your team sounds like it has a fundamental lack of git knowledge which prevented it from successfully making use of the tool, instead falling into anti-patterns and bad habits that may or may not have resulted in delays, confusion, and disruption that would not have been necessary had you actually known the correct way to keep a branch up to date and avoid costly merge conflicts.

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.
      - WHATDOESIT 4y ago
        Well, terms have meanings and it's nice to keep it, makes discussion easier. So yeah sure, we were doing 2 hours-long 1%-of-a-feature branches.
        JimmieMcnulty 4y ago
        It does make discussion easier, which is why your improper use of the term caused such confusion here, and illustrates my larger point; your team sounds like it has a fundamental lack of git knowledge which prevented it from successfully making use of the tool, instead falling into anti-patterns and bad habits that may or may not have resulted in delays, confusion, and disruption that would not have been necessary had you actually known the correct way to keep a branch up to date and avoid costly merge conflicts.