16

I'm working on a project at the moment, and we have the source code up in a private repository on Github, with each of us as a collaborator.

What we are unclear on is how to separate each of our work.

What I think we need to do is:

  1. Each of us needs to fork the repository
  2. When we are ready to push our code, we then submit a pull request to the project leader's repo, who can at the same time use this as an opportunity to do a code review

When it comes to private repositories, is this what forking is supposed to be used for, or am I overcomplicating the situation?

1
  • 1
    Yes. Do it just like you suggested here, only create a team and make the team's repo the "master" repo. Everybody makes PRs, including the project leader. – RubberDuck Dec 8 '15 at 2:01
8

Cloning the repo to the developer's local machine is already a kind of forking. If each developer forks the repo on GitHub, this only serves to publish their current state of work.

This can be appropriate when there is a central master repo, and many contributors that are not trusted with direct access to that repo. This works great for open-source projects where everyone can contribute and issue a pull request that is then reviewed and merged by a group of core maintainers. Using multiple repos enforces a pull-request based workflow.

In a small, trusted team, this is not necessary. To prevent different people getting in each others way, a strategy such as the Git Flow can be followed: Each small feature is implemented on a separate feature branch. When the feature is complete, it is merged into the master branch. Most teams will couple this with a pull request or code review by convention, but are trusted enough to skip that if appropriate. Whereas separate repos would lead to a developer publishing their current state on their forked but team-visible repos, in a single common repo they would push their changes to a separate feature branch. Doing all development on master/trunk is highly discouraged in most workflows.

The difference ends up being solely about access management, and not so much about the implemented workflow. You can do pull-request based workflows with either setup. From a raw Git perspective, there's not much difference between a fork and a branch – either approach essentially shares the history of the project and allows commits to be added without affecting other branches/forks. Considering this, it would be much better to share a single repo when in a trusted, closed group.

4
  • 1
    Just to quickly echo what @amon says, I've worked in an organisation where every developer was required to fork from a main repo, which we all felt was just an unnecessary and clumsy extra step. I never understood why it was required, but our ops team wouldn't discuss it. The process was: commit -> push -> pull request -> wait -> wait some more -> attempt to get the ops team's attention on IRC -> walk over to the ops guys and ask them to look at the pull request -> wait -> code integrated -> repeat. – DaveyDaveDave Dec 7 '15 at 23:46
  • 1
    I really discourage this workflow. I've experienced really bad merge conflicts with two developers both pushing directly to the canonical repo. Not to mention, it's still best to have someone else review your code. It's much easier to submit pull requests if you each have a fork, and there's one canonical project repo. Yeah yeah. I know, that's not "distributed". Whatever. The fork & PR model works better in my experience. – RubberDuck Dec 8 '15 at 1:58
  • @RubberDuck that is a good point, I suspect my case was rare in that the people responsible for pull requests were not in a position to review the code, which made it pointless. I'd suggest other dedicated tools for code review, like gerrit might be more effective, but I do take your point that forking can (should) work similarly well. – DaveyDaveDave Dec 8 '15 at 6:53
  • The problem is who determines when the feature is ready to go into master? I also find it messy to work with branches; 100s of branches on one repo and most of them are unmerged or half-done, why should they exist at all if they aren't even ready to be merged? Access management is 100% about the workflow, this answer is only half good. – Old account Jun 13 '16 at 15:16
5

This would work, or you could use a branching method where each contrib has their own branch(es), that when the team agrees, are merged with master.

1
  • Thanks, going to go with the other answer as has more details, but yes I agree :) – JMK Dec 7 '15 at 22:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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