5 ms·

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

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.
        WHATDOESIT 4y ago
        How come every single article I come across agrees with my definition? https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/... https://www.decodingdevops.com/how-to-create-feature-branch-in-git-or-bitbucket/ https://www.decodingdevops.com/how-to-create-feature-branch-... https://docs.gitlab.com/ee/topics/git/feature_branching.html https://docs.gitlab.com/ee/topics/git/feature_branching.html Could you please post at least one article which describes what you're talking about and what the differences from "just commit/push to main" are? BTW this whole thing isn't about keeping a branch up to date with the main branch - sure that's easy. This is about integrating changes in a small code base where collisions happen often due to small but rapidly changing featureset on which 5 hyperactive developers work on. The only solution to that is to integrate the code very often on a common branch - in our case, around every 1-2 hours, regardless of features being done or not.

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.
        WHATDOESIT 4y ago
        How come every single article I come across agrees with my definition? https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/... https://www.decodingdevops.com/how-to-create-feature-branch-in-git-or-bitbucket/ https://www.decodingdevops.com/how-to-create-feature-branch-... https://docs.gitlab.com/ee/topics/git/feature_branching.html https://docs.gitlab.com/ee/topics/git/feature_branching.html Could you please post at least one article which describes what you're talking about and what the differences from "just commit/push to main" are? BTW this whole thing isn't about keeping a branch up to date with the main branch - sure that's easy. This is about integrating changes in a small code base where collisions happen often due to small but rapidly changing featureset on which 5 hyperactive developers work on. The only solution to that is to integrate the code very often on a common branch - in our case, around every 1-2 hours, regardless of features being done or not.