Improve the fork workflow for teams

Issue #14117 wontfix
Gabriel Marcolino
staff created an issue

We understand that the fork workflow can be used to create forked repositories under the team account, however, this makes the team overview/repository list very crowded.

We would like to list the forked repository in a separated list or/and by projects.

eg. The user "Aby" create a fork named "fork_from_A" She can grant access for every user that belongs to the team. This repository is "owned" by the "Team_A" OR* "Project_A" and it's not listed in the team overview, anyway, it's accessible by the TeamA.

This would provide the user that use the forked workflow, a cleaner view of the team account and a better access control since the repositories would be managed by project and/or would not be listed in the "Main Repository" (overview) of the team.

Comments (4)

  1. Fernando Canizo

    I'm not really sure I really understood this proposed workflow.

    This came up from a ticket I presented. What I really want is the ability to fork from a team account into a personal account and still be able to add permission for reviewers on my personal fork based on the team account.

    Current problem is: if you fork into a personal account, a free one, then you get the limits of the free account, so no matter how much is paying the company account, you cannot select a defined group to add permission to your fork, you have to add them individually and if they are more than four you simply cannot add more.

  2. Alastair Wilkes staff

    Hi Fernando,

    Usually the forking workflow is used in cases where the forker doesn't have write access to the parent repo. Based on your description, it sounds like you might benefit from using a branching workflow instead of a forking workflow for your changes. Is there a particular reason you're choosing to fork?

    If you are committed to using forks, then you'll need to create the fork under the team account in order to avoid this issue. The team account and your individual account are totally separate accounts for billing, and we don't plan to add additional complexity to handle this edge case.


  3. Fernando Canizo

    Our reason for forking: we use topic branches for each story from our pivotal, that means in a week our branch list will become mayhem. Using private forks we only deal with PRs and each developer only sees her own branches on her account and is the only one responsible for managing them.

    I just tested your suggestion with a test repo, the only way to fork inside team account is to rename the repo: that means we will have (currently) ~50 repos x numberOfDevsInTeam final repositories. Add to this that while we can make a convention about the way to name them, it's not enforced by the system, so we may end with different naming schemes.

    I understand the complexity involved, however I don't think our is an edge case.

    Anyway, thanks for stepping in.

  4. Alastair Wilkes staff

    Thanks for the additional explanation, and apologies - you're right, my suggestion could lead to many similarly named repos.

    Honestly, we'd still recommend using branches instead of forks for this workflow - we use this every day across large teams - it's really the workflow we're focused on, so we'd prefer to improve the experience using branches across large teams instead of using forking as a workaround. If you'd be willing to give it a go, we'd love to chat about it!

  5. Log in to comment