2 Expanding
source | link

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.

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.

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.

1
source | link

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.