Why do Rietta Developers Git Fork?
Why Fork a repository?
Forking a open source project is the standard way for collaborators such as ourselves to fix bugs, experiment, and add features to existing open source projects without affecting the main repository. We can use the Fork feature on Github to create a repo on Github in which is a clone of the original repo we forked.
Github has a great article https://help.github.com/en/articles/fork-a-repo that explains how we can fork off from a repository on Github.
For starts, we need to clone the forked repo to your local environment:
git clone git@github.com:your_username/repo_name.git && cd repo_name/
After we clone our copy of the repo, we need to add the parent repo, which we’ll call upstream, as a remote named upstream.
git remote add upstream git@github.com:organization_name/repo_name.git && git fetch upstream
The purpose of this step is to stay consistent with the version of the original repository on your local environment. It should be regular practice to use git fetch upstream && git rebase upstream/master when developng and creating new branches/features.
This will decrease the chance of the development environment not being in sync with the original repo which can help avoid merge conflicts.
By having control over what pull requests can be merged into the master repository, the git history can stay consistent according to the style-guide for that particular codebase owner. Internally, we also like to keep our git logs clean for both future development efforts but also for security reasons.
As the creator of Git once said in a thread called git rebase: you’re doing it wrong,
People can (and probably should) rebase their private trees (their ownwork). That’s a cleanup. But never other peoples code. That’s a “destroy history” - Linus Torvalds
Why we Fork internally at Rietta
Another Rietta staffed put forking this way:
Forking the repository walls off the client repository to protect it from unpolished code and allows developers to control their pull requests. Just like the principles of how we contribute to open source software, our development process works off of forks and contribute by making pull requests towards the remote(original repo).
This separation as mentioned by Linus Torvalds, helps keep pull requests tidy and most importantly helps keep the git log consistent and maintainable. By utilizing rebases, the developer can keep work-in-progress branches up to date and clean. By utilizing some features on Github as shown on our other blog What Is the Difference Between the 3 Github Merge Types?, we can keep the main repository’s git history readable and very useful to flip through when debugging issues.
By having forked repos, we can ensure pull requests are abiding certain organizational repo’s git message/log rules. This protection also extends to preserving the original source code and only merging in changes after being approved and properly code reviewed by peers or repo owners.