16

I'm looking for the best practice, forking vs branching on GitHub. I've read this Forking vs. Branching in GitHub, but it's not relevant.

Our team of 5 people are working on the same repository, and we would like to avoid merging problems, conflicts or regression in the code. The goal is for the 5 persons to work on different parts of the project, often on the same file.

I would like to know if it's worth it to :

  • fork the project, work and create pull requests, so each persons can review the code easily, or
  • create a new branch - work and merge on master when work is done.
random
  • 9,324
  • 10
  • 63
  • 77
Erowlin
  • 4,314
  • 3
  • 28
  • 58
  • Both of the options you suggested are identical from git's perspective, and nearly identical from GitHub's perspective (you can create pull requests from branches in the same repository). – Ajedi32 Jul 29 '14 at 13:55
  • Thank you for your edit @random. Since I'm looking for the "best practices", I would like more comments of how it's done by differents companies, and the pro/cons of each options. – Erowlin Jul 29 '14 at 13:58
  • @Ajedi32, I'm not looking from git's perspective, but from developer's perspective. – Erowlin Jul 29 '14 at 13:59
  • @Erowlin From the developer's perspective, a fork is just another git remote they can push to. Really I don't see a big difference either way. – Ajedi32 Jul 29 '14 at 14:14
  • 1
    Here's a whole list of possible git workflows you can use: https://www.atlassian.com/git/workflows – Ajedi32 Jul 29 '14 at 14:16
  • Thank you @Ajedi32, that's some links like those I'm looking for. – Erowlin Jul 29 '14 at 14:17
  • In a team of 5 collaborating towards a common goal I do not see any advantage in forking. Branching is more lightweight and in my mind more accurately reflects the end goal of having all 5 contribute to the same outcome. Although functionally not particularly different, forking almost implies you are all going to be pulling the code base in largely different directions, more loosely sharing code. Assuming you are in the same organisation, have a common goal and trust one another - branching is the way to go for you I think. – Montdidier Aug 05 '14 at 03:37
  • Possible duplicate of [Forking vs. Branching in GitHub](http://stackoverflow.com/questions/3611256/forking-vs-branching-in-github) – Aidan Feldman Dec 17 '15 at 19:47

6 Answers6

24

To me, the best practice when dealing with a project with more than one developer, is to use gitflow branching model.

First, the master branch will now only be used to keep track of the releases of your app, major, minor or patch versions, following the Semantic Versionning.

The develop branch will be the core of your project, since it will make the bridge between the different features and your releases.

This system helps to reduce the number of merge, just as a simple branching system will do, but add the semantic logic, and the friendly and simple commands that comes with it.

For more info about gitflow you can follow this link.

Qantas 94 Heavy
  • 14,790
  • 31
  • 61
  • 78
Balthazar
  • 33,765
  • 10
  • 77
  • 104
  • In general practice, we keep Prod branch. In your reference, gitflow, they call prod as master (which might be little confusing). I don't understand how it can reduce the number of merge, as the question says, many developers are working on same file (in different branch) ?. – Sairam Krish Aug 06 '14 at 06:32
  • 4
    Just for fun, @Aperçu is now working with me at the same office, sitting in front of me. We didn't know each other until last week, and it's a coincidence. We noticed it when he looked at my StackOverflow account. – Erowlin Oct 13 '15 at 07:01
  • With respect to the original question, I agree with Sairam Krish - while gitflow has a lot of benefits, this just pushes [most of] the merges into the develop branch instead of master. Even with release, hotfix, and feature branches, you still need some method of managing merges. In the end, branching is great for smaller, integrated teams, generally in the same management structure. Forking is more appropriate for random contributors and large, multi-team environments, where there are separate pockets of development. – LightCC Sep 11 '17 at 09:32
11

Maintaining forks introduces additional overhead as each fork needs to pull changes from upstream. I see no benefit to doing so when every developer can have access to a shared repository.

Pull requests can be a very useful mechanism for code reviews but they do not demand that you use forks. You can create branches in the same repository and use pull requests to manage merging them into your master branch.

Jonah
  • 17,609
  • 1
  • 41
  • 68
  • Your response is acceptable, but I'm looking for more responses and point of views ! Thank you. Does the creation of a pull request each time will not annoy people ? – Erowlin Jul 26 '14 at 09:25
  • 2
    If you want to force code reviews and this is the policy for your project, why should it annoy people? – martin Jul 31 '14 at 11:24
5

At my office we have a similar situation: a large project where five or more developers have commit access, and typically at least three are working on it at any time. We manage everything using a single repository with branches and pull requests, and we haven't had any issues (that were caused by our source control setup, anyway).

Pull requests are an excellent way to solicit code reviews from other developers, which is especially important when those same developers may be working with your code the next day. Forking, on the other hand, doesn't really provide any benefit; it is a solution to the problem of allowing broader access to a controlled codebase, and that problem just doesn't exist when everyone has commit access to the repo.

Wally Altman
  • 3,365
  • 3
  • 24
  • 32
3

Atlassian has an excellent write up on the differences between forking and other git workflows on their git tutorials page. (See Forking Workflow | Atlassian Git Tutorial)

Relevant quotes:

The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.

...

It’s important to understand that the notion of an “official” repository in the Forking Workflow is merely a convention. From a technical standpoint, Git doesn’t see any difference between each developer’s public repository and the official one. In fact, the only thing that makes the official repository so official is that it’s the public repository of the project maintainer.

...

All of these personal public repositories are really just a convenient way to share branches with other developers. Everybody should still be using branches to isolate individual features, just like in the Feature Branch Workflow and the Gitflow Workflow. The only difference is how those branches get shared. In the Forking Workflow, they are pulled into another developer’s local repository, while in the Feature Branch and Gitflow Workflows they are pushed to the official repository.

Ajedi32
  • 36,408
  • 19
  • 117
  • 155
2

I would work in a "centralized" way, that is, having a main repo that everyone fork, every developer would commit to their own repo, that makes the code review process easier. Once the code review has been done you can merge the changes to the main repo.

This is just the main idea...

You would also need to set up the strategies on how to branch. I would recommend Nvie model

Guillermo Mansilla
  • 3,601
  • 2
  • 24
  • 34
1

I feel, the bottleneck is not forking or branching. In both approaches, you need manual intervention of merging / reviewing the changes.,

So the bottleneck is with the application development approach. I see a problem, when a team is collaborating on the same file. With a proper architecture design, can it be split as separate modules with individual files ? On runtime or build time, the separate modules (or files) could be aggregated to form the whole feature (or a single file).

If we could solve it in that level, once the team size increases or the feature complexity increases, things will be smooth to scale.

Sairam Krish
  • 7,037
  • 2
  • 40
  • 53