user3331119
user3331119

Reputation: 245

Private Git Forking Workflow and Collaborative Features

GitFlow is a very popular branching model that has become somewhat of an industry standard (http://nvie.com/posts/a-successful-git-branching-model/). In addition to maintain workflow consistency with the open source community and control repository access Forking Workflow as used where the primary repository is locked down and all contributors work from forked repositories. Non-admins file pull requests for merging their forked repo changes and admins review and merge that code. This can be done with private organization repositories as well. (https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow) Forking Workflow and GitFlow are used in conjunction to manage software projects.

My question is around collaboration while using the Forking Workflow. When multiple engineers need to collaborate on the same feature and have made progress how do they share the code? With GitFlow it's easy to just push a feature branch where team members can conveniently work together. The problem is that with Forking Workflow it requires someone to accept pull requests before the code is merged and accessible to all the feature collaborators. How do feature collaborators contribute to the same in-progress feature without requiring the attention of someone to constantly accept pull requests?

Upvotes: 2

Views: 220

Answers (1)

user3331119
user3331119

Reputation: 245

I found an answer I consider to be an acceptable one. If someone finds something better I'll update this.

Basically, feature branches are worked off of a team lead or central user's fork. The branch can be pulled into a local repo and pushed back to the fork.

See "Contributing to other developers' forks" (http://x-team.com/2013/09/our-git-workflow-forks-with-feature-branches/) for more details.

Upvotes: 1

Related Questions