4 ms·

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) o

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.
      - JimmieMcnulty 4y ago
        What? You want an "article" that describes how git branching works? Here.[0]. > Some people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. It's really not hard, a "local copy" is a branch. If you can't manage what you just described trivially, you need to learn git better, because I, and everyone else who knows how to use git, can manage those things trivially, and have successfully for many years now. Your solution was the wrong one, homegrown to avoid dealing with the reality that you and your team didn't know how git works. All of this would be fine, by the way, had you not proposed others listen to you. Exactly zero people should do as you have described. [0] https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N...

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.
    - JimmieMcnulty 4y ago
      What? You want an "article" that describes how git branching works? Here.[0]. > Some people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. It's really not hard, a "local copy" is a branch. If you can't manage what you just described trivially, you need to learn git better, because I, and everyone else who knows how to use git, can manage those things trivially, and have successfully for many years now. Your solution was the wrong one, homegrown to avoid dealing with the reality that you and your team didn't know how git works. All of this would be fine, by the way, had you not proposed others listen to you. Exactly zero people should do as you have described. [0] https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N...