Search code examples
workflowforkgit-branchgitlabgit-workflow

With "protected branch" provide by GitLab, we don't need fork button?


I trying using GIT few weeks. And Trying to understand some workflow with Git. Then I setup a Gitlab server for permission management. After look around the GitLab service, i notice that gitlab support fork workflow by an embedded button. but also support the ability to protect a branch.

I think the "protected branch" ability can use to replace the fork button, am i right or there is some concept i don't get it?

here is why i think that way: In fork-workflow, only maintainer can push to the official repo, so cooperator fork the official repo as upstream repo, clone the upstream to local working copy, after finish a feature branch in local we push to our upstream than do the pull request to maintainer, but if we want fetch the fork repo with official repo, we do it by pull official repo and push to upstream. its....i don't know ... a little too non-auto, not like working in a team.

but use protedted branch, there is no fork upstream, cooperator have permission push to official, but only maintainer can push the protected stable branch, and we don't need sync the fork repo by hand. maintainer don't need add many remote for get cooperators new feature.

is this a convenient version fork-workflow? and can completely replace the fork button?


Solution

  • its....i don't know ... a little too non-auto, not like working in a team.

    It is facilitating contribution by non-contributors, meaning precisely by people who are not part of the team!

    That avoids having to manage:

    • hundreds of team members (only a select few can impact your repo)
    • hundreds of branches (for those hundreds of team members to push to, since they are likely to work on different features)

    The fork introduces a workflow which means to:

    • ease the process to replicate a repo and start experimenting
    • identify motivated contributors who will actually make pull requests.

    If their PR are good and consistent enough... they could end up part of the team of the original repo!
    And that original repo can still benefit from a protected branch, maintained only by an integrator: that is an internal workflow decision.