Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

Question on using "Git flow"

Discussion in 'Open Projects' started by Erenquin, Oct 3, 2020.

  1. Erenquin

    Erenquin

    Joined:
    Apr 9, 2018
    Posts:
    164
    Hello,
    at my work we use the actual "Git flow".
    Basically you have a "develop" branch beside the master branch.
    You work on a feature branch, which is based on the develop branch and pull requests goes to the develop branch.
    Then at release time develop is validated, and merged to master (and master is validated too).
    (I simplify, develop is validate all the time).

    I suppose it is too late to change this, but I find that easier rather than having everybody forking the whole repo + managing its maintenance.
     
  2. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    It's never too late and I was considering it.

    However, if we create a
    develop
    branch on the official repository, you would still have to fork it. Or did I misinterpret it?

    The other thing is that whoever already forked, on their PR, would automatically push to
    master
    for now, at least on their first PR. Which means we'd have to say a few times "Push to
    develop
    please". Might be ok.
     
    Proryanator likes this.
  3. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    After a bit of consultation, we decided to stay the course and keep
    master
    as our main branch, and merge PRs there. At the end of the day if you think about it, all of the
    master
    s on the various forks are basically development branches and we have the PR mechanism to protect the main branch.

    Later on we might spin off a `release` branch on which we put milestone builds? That was always the plan.
     
  4. Erenquin

    Erenquin

    Joined:
    Apr 9, 2018
    Posts:
    164
    Juste to be sure we are on the same page, I'm talking about the git flow process as described here: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

    Some tools like Sourcetree integrates this process in their UI.

    "However, if we create a develop branch on the official repository, you would still have to fork it. Or did I misinterpret it?"
    I wonder if you do not confuse "fork" and "clone".
    With this process everybody will have to clone the repo, but not fork it.
    The idea behind my proposal is precisely to avoid forking the repo.

    But after writing my post I realised that with many people working on the same repo it may quickly become a mess with so many feature branches, etc ...

    Yet I'm afraid that merging to master (even with a PR and code review, especially at the beginning with no unit tests), you may break the master, which should be stable at all times.
    While with an intermediary develop branch (tested & validated before going to master) , you may break the develop branch, but not the master branch which stays safe.
     
  5. default_team

    default_team

    Joined:
    Dec 1, 2018
    Posts:
    21
    I think we'd work on feature branches on our forks anyway. Then we'd be creating PRs from our feature branch to the upstream project's `master` or the `develop` branch. If we commit directly into fork's master, our master branches would get deviate from the origin's master, which is a problem.
     
    Last edited: Oct 6, 2020
  6. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    We really can't avoid having people fork the repo. Avoiding that means giving everyone writing rights to the repo, which would result in a big mess :)

    I know, but:
    And then it would be the same as potentially breaking master, but not breaking the release branch.
     
    RunninglVlan likes this.