I remember when 3D printers were first becoming accessible to everyday makers. One of the new printers touted its ability to replicate itself by printing parts that could make another 3D printer which could print parts for another 3D printer, and so on.
This recursive concept was really interesting, and something I thought about when we were asked this question in one of our recent GitKraken community Slack AMAs:
“Do you manage GK source code completely from GK? If so, how long did it take to be self-sufficient?”
Just like those self-replicating 3D printers, we do in fact use GitKraken to make GitKraken and have been doing so since around version 0.0.3, when it was just a tiny baby Kraken. Using only GitKraken, even in its infant state, was an important exercise that helped ensure we were including features that developers actually needed. It helped us to constantly improve the user experience with each release—because a “powerful” tool that is awful to use isn’t much good to anyone.
If you’ve ever wondered how developers use their own tools that make those same tools, allow me to give you a bit of insight into our process, and show you how GitKraken is vital to its own creation. In this existential journey, you’ll learn how GitKraken devs use GitKraken to make GitKraken.
Imagine you are new to the GitKraken team and eager to start contributing to development. You have a GitHub account right? You do. Everybody has a GitHub account (how do you think grandma submits pull requests to the Linux repo?). So, we would give you access to the GitKraken repository on GitHub (lucky you!) where you would fork your own copy of the GitKraken source code. This is important because it gives you your own safe sandbox to play in without breaking the production version of GitKraken.
Equipped with a safe repo with which to experiment, you’d download and install your own copy of GitKraken, skipping the task of installing Git altogether if you so choose. Then, since you’re working on a GitHub hosted repo, you’ll want to take advantage of GitKraken’s powerful GitHub integration by signing in with your GitHub account. This allows GitKraken and GitHub to talk with one another in a seamless way.
You’ll get a glimpse of the power when you go to clone the GitKraken repo. Instead of going back to GitHub to get a clone URL, just pop into the GitHub tab in the Clone menu, and search for the repository you want to clone. Because you’ve connected GitKraken with GitHub, all the repos you have access to will be searchable in GitKraken for easy cloning.
With your repository cloned and opened in GitKraken, you’ll have a local version on your machine and a remote connection (origin) already set up to the main GitKraken repository on GitHub. Remember that fork you made on GitHub? You’re going to add that as a remote, using that slick GitHub integration, to find your repo on GitHub instead of leaving GitKraken.
squid-chan remoteAll GitKraken developers work from their own forks of GitKraken. Adding those as remotes in GitKraken gives us an overview of who is working on what, and makes it easy to check out someone else’s branch to collaborate with them or review their work. We can also hide the remotes we don’t need to see, keeping the graph tidy. This reduces the number of auto fetches that occur to keep everything up-to-date. Hidden remotes can still be fetched manually from the context menu with a right-click.
Having personal forks of GitKraken makes creating pull requests (PRs) on GitHub even easier thanks to drag-and-drop actions in the left panel. Most of our work is merged into development first for review and testing before it is included in a staging build. When a developer has finished working on a branch, that gets pushed to their remote where it can be dragged and dropped onto origin/development to start a PR from GitKraken.
GitKraken’s GitHub integration continues to save time in our workflow by allowing us to open a PR with all of the relevant information pre-filled in a simple form. All we need to do is add a basic title and description then submit it to GitHub. For more detailed editing, the PR can be easily opened in GitHub directly from GitKraken.
After pull requests are created, we assign developers to review them using GitHub’s pull request review system. In GitKraken, we keep track of open PRs in the left panel and can easily open them in GitHub to review.
Upon approval, a mysterious DevOps process occurs that merges that PR into development, which is used for staging builds for QA to check, and eventually a shiny new release is bestowed upon the world for all to enjoy. Pulling back the curtain on that is an article for another day.