0

For reasons unknown to me, forking repositories is not allowed in gitlab in our company. The idea was to allow the developer to fork and create a merge request which will then be approved and post approval the code will be pushed to the main repository.

Now since we do not have the forking option available, I was thinking to allow the developers to create branches, the developers will push the code in their branch and then raise a Merge request and on approval the code will be pushed to the main branch.

Will that be the right approach or are there any other approach that we can look at?

Improve this question
3
  • its a good approach, better than forking imo. not sure what you are looking to avoid/gain with an alternative?
    – Ewan
    Jul 6, 2018 at 13:01
  • I was trying to understand if this was the right way of doing it?
    – Sam
    Jul 6, 2018 at 13:04
  • well, I've seen it done that way, but presumably you want some feature of forking which it doesnt support?
    – Ewan
    Jul 6, 2018 at 13:06

2 Answers 2

Reset to default
4

Forking and branching are pretty much the same as far as Git itself and team-oriented Git workflows are concerned. In your local repository you may have any number of remotes. When you fetch updates from them you can see the remote branches locally, prefixed by the name of the remote repository. So there might be a team/master and an anamadeya/master and your local master branch. The fork is just another set of branches.

So why are forks common in open-source development? Because of access control. A contributor can publish changes on their fork, send me a pull request, and I can merge their changes into my repository. So I don't have to give write access to everyone who wants to contribute.

In a team this is irrelevant: everyone can be given write access. You can trust each other to not abuse that access. So using multiple forks has no additional value. You can simply push your work on a separate branch and issue a pull request (gitlab: merge request) for that branch when it is ready. Keeping everything in a single repository also makes it easier to integrate external CI tools and to use issue tracking software effectively.

Improve this answer
1

Git is designed to be a decentralized versioning system. A local clone on your machine could be called "fork". But using the term "fork" is a bit misleading.

Working in a team usually has the obligation to push local changes to a centralized repository every day. If it might break the other code, the changes should be maintained in a branch and merged into master or developement branch, as soon as they are stable to avoid merge conflicts.

If you have private "forks" in gitlab, other cannot see your changes and can have similar effects to not pushing changes at all:

  • Somebody might fix bugs, you already have fixed. But he can't see.
  • Nobody can check for merge conflicts on difficult changes, cause your branch is not available.
  • If you get sick, nobody has the access rights to merge your important feature or to continue your work

You can workaround these negative effects, but they might be the reason to disallow "forks".

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.