3

github encourages 1 fork per user, so that that user can work independently on a feature and then request that feature to be accepted into the main repository via pull request.

However, what if 2 developers need to collaborate on that feature? What is the ideal workflow for this? I could see a number of options:

  1. Both developers fork the original repository. Each developer pulls/pushes changes between each other's repository. This seems like a lot of work (tiny micro operations) and also creates a delay between changes, so increases the window for conflicts.
  2. Developer 1 forks from the main repository, developer 2 forks from developer 1. Same as #1 mainly but hopefully simplifies Developer 2's life a little?
  3. Developer 1 gives Developer 2 permissions to his own fork, so they both work out of the same central repository. Not sure if this is ideal.

I'm also curious where branches come into this. Obviously there would be a branch for the feature itself but that branch can't exist in a single place, it would have to exist on multiple forks and be synchronized.

Basically just really confused about this workflow, would like an approach for how this can be best accomplished.

void.pointer
  • 4,983
  • 8
  • 30
  • 40
  • How is 'pull from other repository' really different than 'pull from common repository'? You *can* set up multiple remotes and do `git pull otherGuy branch` which isn't fundamentally different than `git pull origin branch` –  Oct 29 '13 at 17:17
  • That's no different than granting 2 users access to the same repository on github. That's what forking a project does. – Izkata Oct 29 '13 at 18:24
  • 1
    The feature branch is going to depend on how the owners of the main project want you do handle it, IIRC. – Izkata Oct 29 '13 at 18:29
  • This may help: http://programmers.stackexchange.com/questions/88099/github-team-workflow-to-fork-or-not?rq=1 – Michael Durrant Oct 29 '13 at 19:49

1 Answers1

7

Create a feature branch for the functionality that you'd like to implement.

Both developers will pull a local copy of the feature branch. They can push incremental progress to the feature branch, and conflicts will be resolved via merging, should they arise.

EDIT

The way I would approach this problem:

  1. From the main, up to date repository, create a branch git checkout -b FeatureBranch
  2. Both users checkout this branch git fetch and git checkout FeatureBranch
  3. Now each user has a local copy of FeatureBranch on their machine
  4. Each user is able to progress individually on their local branch, committing changes as they please. When enough progress is made, they can each push their changes to the remote branch git push origin FeatureBranch. Git will handle merging automatically, unless a conflict arises that cannot be automatically resolved. In this event, the pusher will have to manually resolve it.
  5. When the feature branch is ready to be merged back into master, issue a pull request, or git merge

FYI I think you have your terminology mixed up in your post. Users should create a branch from the master branch, and upon completion of their work, they issue a pull request and the admins can decide to merge it in or not. Forking, at least in my mind, is reserved for taking a project at a certain point, and heading in a different direction with development. If a feature branch is intended to enhance the current code base, and fits the ideology and paradigm of the project, I would recommend branching.

Perhaps some more background information about your use case would be helpful.

DaveWeber
  • 116
  • 4
  • This, however, implies that both developers have access to push changes to that feature branch (as mentioned in option #3). The OP seems to have misgivings on this approach - is there anything you can say to alleviate those fears? –  Oct 29 '13 at 19:47
  • The difference between this option and the OP's option #3 is that the feature branch isn't any one user's "user branch", so neither user is putting their private branch at risk of getting junked. Users can pull directly from the feature branch, or if you want to be completely anal about approving uploaded changes, branch the branch to create "user feature branches"; users will commit to their user feature branch, ask whomever should approve said changes to push them into the feature branch, then when the feature is mature, ask for approval to push the whole feature back to the trunk. – KeithS Oct 29 '13 at 20:02
  • ... And BTW, @DaveWeber, welcome to Programmers.SE. – KeithS Oct 29 '13 at 20:02
  • Thanks KeithS. @MichaelT, I thought the misgivings were related to collisions in their work, in which case, as KeithS mentioned, would not be as problematic because there is still a local and remote branch, instead of directly managing each other's local copy. – DaveWeber Oct 30 '13 at 21:18
  • Could you add that (and KeithS's clarifications too) to your answer? Explaining out the full domain and context of the answer in the answer is what I was trying to get at. How does this workflow work? git is something that tends to get an large number of views and having the best possible answer can help those future visitors understand what you are answering and how it fits into the overall git philosophy is key. –  Oct 30 '13 at 21:28
  • @MichaelT I've done so now. Hope it helps. – DaveWeber Oct 31 '13 at 00:30