I used CVS and ClearCase before moving into Git, and it took me some time to adjust to the fact that the cost of branching in Git is much much less than ClearCase. And getting into the “distributed” mindset didn’t happen overnight.

  • @[email protected]
    link
    fedilink
    176 months ago

    I think a common misconception is that there’s a “right way to do git” - for example: “we must use Gitflow, that’s the way to do it”.

    There are no strict rules for how you should use git, it’s just a tool, with some guidelines what would probably work best in certain scenarios. And it’s fine diverge from those guidelines, add or remove some extra steps depending on what kinda project or team-structure you’re working in.

    If you’re new to Git, you probably shouldn’t just lookup Gitflow, structure your branches like that, and stick strictly to it. It’s gonna be a bit of trial-and-error and altering the flow to create a setup that works best

      • @Matriks404
        link
        46 months ago

        At that point you might as well add an alias that does all these three things.

    • @[email protected]
      link
      fedilink
      English
      26 months ago

      I think a common misconception is that there’s a “right way to do git” - for example: “we must use Gitflow, that’s the way to do it”.

      I don’t think this is a valid take. Conventions or standardizations are adopted voluntarily by each team, and they are certainly not a trait of a tool. Complaining about gitflow as if it’s a trait of Git is like complaining that Java is hard because you need to use camelCase.

      Also, there is nothing particularly complex or hard with gitflow. You branch out, and you merge.

      • @[email protected]
        link
        fedilink
        26 months ago

        Well to be clear, this was not supposed to be a jab at gitflow, or me complaining specifically about gitflow. I merely used “gitflow” as an example of a set of conventions and standardizations that comes nicely packaged as one big set of conventions.

        But there’s nothing wrong with gitflow. I was just saying - it are not set in stone rules you must follow religiously. If you’re using it and it seems more practical to adapt the flow for your own use-case, don’t worry it’d be considered wrong to not stick strictly to it