[Housekeeping] Change from branching to forking

[MadsBuchmann]

• I have written a good issue

Describe the housekeeping request

I think we should look into utilising forks instead of branches.

When a contributors forks a repository, it is essentially cloned to their own GitHub account. The contributor can then make the desired changes in their isolated clone of the repository. When they are done, they can then request that their forked version of the repository is merged with the original repository.

Much like what Is done with branches.

A major benefit of using forks above branches, is that contributors do not need to have permissions to push a branch. Everyone can create a fork and request to have It merged back to the original repository.

Which means we do not have to mess around with permissions whenever someone new wants to contribute. This would make the process of contributing easier.

Also it would allow us to use branches for other purposes. For example we could have an experimental branch or perhaps a branch where all changes for the next major version is committed.

This is just some initial toughts, but I think there would be much to gain from it.

Additionally I think this stack overflow comments does a good job of explaining the high level differences: https://stackoverflow.com/a/34343080/3482631

Are there any additional context?

#1842 would have to be fixed

[MadsBuchmann]

@RasmusKjeldgaard @jkaltoft I would like to hear your toughts on this 🧠

[MadsBuchmann]

Also I converted this into a discussion as it ain't very actionable.

[RasmusKjeldgaard]

I like it! And if we do it, we should remember to go and remove the write access of all the people who are currently invited to contribute.

I think we should create a wiki-page inspired by the stackoverflow post, alongside a small guide on how to do this, if we go down that road.

I like the idea of having branches only for release management, so we can pile up multiple breaking changes into major releases and so on. Good stuff!

[jkaltoft]

There seems to be some benefits to using a forking strategy, although I am a bit concerned with each of the cons mentioned in https://stackoverflow.com/a/34343080/3482631

I'm also not complete sure what they mean by Your team process reflects the external contributor process and Your team contribution process doesn't match the external contributor process.

However, in general I think we should give it a go. I haven't used forks before. Well, I have forked repos, but I haven't used forks as a workflow for collaboration.

[MadsBuchmann]

Regarding "Your team process reflects the external contributor process".

I think the author of that answer is assuming a context where the core team uses branches and external contributors use forks for contributing (which is quite common across open source projects AFAIK). The inquirer is trying to decide whether to use branches or forks for the core team of the project, as I read it.

Having tought a bit more about it and having talked with others about it, I think the best approach might be to:

• Have the core team i.e. Team Kirby use branches as normal
• Have external contributors use forks

I think this has the following pros:

• The core team can easy collaborate across branches and does not need to invite each other to contribute to forked branches
• External contributors does not have to be invited to the project and can just create a fork instead.
• If an external contributor want to cooperate with someone e.g. someone on their team; they can just invite them to their fork. We do not need to handle anything in that case.
• External contributors does not have to deal with branch naming conventions
• We will not get branch bloat as the number of external contributors rise

If we go with that approach we will still have some branches besides the ones used for releases. But we could consider naming release branches with only numerals such that they will be sorted at the top of when browsing branches on Github, e.g. 1.0.0.

[jkaltoft]

I think we should pursue this direction 🚀

[MadsBuchmann]

@RasmusKjeldgaard what do you think about this approach in relation to your toughts on release management?

[RasmusKjeldgaard]

💯 , I think it makes sense. I don't believe forking will have any consequences related to release management, as we will have to find a general way to control how and to where features are merged, no matter if they reside in a branch in our repo or in a fork.

[jkaltoft]

Found another (random) blog post about the "fork-and-branch workflow" that could be a starting point for a guide for contributors:

Basically, the “fork and branch” workflow looks something like this:

• Fork a GitHub repository.
• Clone the forked repository to your local system.
• Add a Git remote for the original repository.
• Create a feature branch in which to place your changes.
• Make your changes to the new branch.
• Commit the changes to the branch.
• Push the branch to GitHub.
• Open a pull request from the new branch to the original repo.
• Clean up after your pull request is merged.

https://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/