4 ms·

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...
    - WHATDOESIT 4y ago
      You can't really do feature branches without knowing how branching in Git works... > It's really not hard, a "local copy" is a branch. For sure. Not necessarily a "feature branch" though. That's a more specific thing described in the articles I linked, building on top of the basic Git feature you linked.
      - JimmieMcnulty 4y ago
        I didn't say you could, I said your proposed "never use any branch other than main" was both factually incorrect (your team literally didn't do that) and not how the git tool was designed (merging branches into a main branch is trivial, and in fact how the tool was designed).
        WHATDOESIT 4y ago
        Sorry that I didn't explicitly say "local copy of the main branch". I thought that's a given. Not that it's really relevant though... Still the same problem with feature branches - if you don't integrate often the code will change under your hands and you won't be able to use the code others made until you integrate with them. Please understand that "feature branch" is a technical term describing a very specific branching strategy - and you're not going to find its definition in the Git docs; I think it was originally defined by Atlassian (but not quite sure). A local copy of the main branch with a few additional commits that you're going to push to the origin way before the feature is complete is not a "feature branch" as commonly defined.
        JimmieMcnulty 4y ago
        You're claiming what your team did wasn't "develop features in a branch", when you did precisely that.
        WHATDOESIT 4y ago
        No, I am claiming "our team didn't develop features in feature branches". Local copy of the main branch is a branch too, I know that very well. But it's definitely not a "feature branch" - it's not named after the issue number, it's merged way before the feature is complete, no PR is created, etc.

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...
  - WHATDOESIT 4y ago
    You can't really do feature branches without knowing how branching in Git works... > It's really not hard, a "local copy" is a branch. For sure. Not necessarily a "feature branch" though. That's a more specific thing described in the articles I linked, building on top of the basic Git feature you linked.
    - JimmieMcnulty 4y ago
      I didn't say you could, I said your proposed "never use any branch other than main" was both factually incorrect (your team literally didn't do that) and not how the git tool was designed (merging branches into a main branch is trivial, and in fact how the tool was designed).
      - WHATDOESIT 4y ago
        Sorry that I didn't explicitly say "local copy of the main branch". I thought that's a given. Not that it's really relevant though... Still the same problem with feature branches - if you don't integrate often the code will change under your hands and you won't be able to use the code others made until you integrate with them. Please understand that "feature branch" is a technical term describing a very specific branching strategy - and you're not going to find its definition in the Git docs; I think it was originally defined by Atlassian (but not quite sure). A local copy of the main branch with a few additional commits that you're going to push to the origin way before the feature is complete is not a "feature branch" as commonly defined.
        JimmieMcnulty 4y ago
        You're claiming what your team did wasn't "develop features in a branch", when you did precisely that.
        WHATDOESIT 4y ago
        No, I am claiming "our team didn't develop features in feature branches". Local copy of the main branch is a branch too, I know that very well. But it's definitely not a "feature branch" - it's not named after the issue number, it's merged way before the feature is complete, no PR is created, etc.