Tools’ Flexibility: Forks & Remote Pull Requests
Most of the existing git hosting tools are super flexible and definitely that is something that developers love and encourage. However, this doesn’t always apply when you need to define strict software company policies, specially if you are working at big corporations.
There is a clear lack of branch management control for those companies that need it. For example, how can you control that only a set of developers push to master? This might sound like a silly question, but organizations are using all kind of “hacks” to make it happen.
Hack: Fork an internal repo and create a remote pull request
Many companies decided to start using a “workaround” for this situation: every developer forks the main repository and when he is done, he creates a remote pull request to the main branch in the main repository. Companies only give write access to the main repositories to a few members of the dev team (“mergers”) and because of that, they are the only ones with the option to merge or push to master.
Gitcolony “forked” Live branches: How to hack the hack
With Gitcolony, manage your fork as if everything was held on the same repo. You can fork your repo and work on the forked branches as if they were live branches. You can review them partially, without even waiting for a remote pull request! At the same time, you can give your team visibility: they can see your forked branches while you keep working, so they don’t need to wait 2 o 3 weeks for a PR in order to review those branches. Awesome, don’t you think?
Improve your experience: Gitcolony’s business rules engine
We consider that this “hack” was an acceptable way to workaround the lack of branch management on existing tools, but we decided to go even further and not only improve the current experience but also redefine it and make it even more efficient.
Thanks to Gitcolony’s business rules engine you can control (and rollback through a PR if necessary) that nobody pushes directly into your defined branches. But that is not all; you can define a list of “trusted mergers”, those are going to be the only users that can close a PR or merge a branch into your main branch.
As we love to say: “With great power comes great responsibility”, so manage it wisely and have Gitcolony to make your dev’s life easier :)