I remember when I started working with data there was one tool, a system, at the sound of which I would get shivers. I was feeling bad because I was getting green at the thought of using it. Really. It seemed to me very much like the perfect tool to destroy someone’s month of work. Or two.
All in all, why am I making a mystery to you, since I have spoiled the news in the title? Speech control version — git. Please don’t laugh at me, it was really giving me panic attacks.
As an analyst, many times experience has shown me how important it is to show analogies—finding simple examples from life to explain difficult things. Technical stuff. That’s why today I’m going to tell you why when you use git it’s like playing around with a cookbook.
— —
Imagine walking into your kitchen, full of desire to create culinary delights. Just as you need a cookbook, you turn to Git in the world of coding.
You’ve decided to collect your family’s family recipes into a cookbook. This important collection, full of memories and secret ingredients, is like your own Git repository, a place to store all your coding projects.
In practice, a repository is the location where all the files for a particular project are stored. It contains all of the project’s files and keeps a history of changes to each of them. Repositories can have multiple contributors and can be public or private. A repository also keeps track of changes and versions and allows you to roll back to earlier versions (my lifesaver!) or branch out to try new features separately.
Now imagine that your book has been inspired by a friend, maybe you even want to co-create it. He asks you for a copy of the cookbook to try out some of the dishes and perhaps add some of his variations to it. So you give him a photocopy. This action mirrors cloning in Git, where you take a copy of a repository to experiment or make additions without changing the original.
Cloning in Git means creating an identical copy of a repository on your local computer. This allows you to work and experiment with code without affecting the original version. This is especially useful when you want to contribute to someone else’s project. With this copy, you can make changes, test them, and then propose those changes back to the original repository.
When cooking, you often adjust recipes to your preferences, noting changes in the margins — a little more sugar here, less salt there. In Git, this act of noting changes is to commit. It’s a way to keep track of every change you make, ensuring that nothing is lost in the process.
Commit in Git is like recording changes made to a local repository. Each commit captures a snapshot of the code at a specific point in time and has (should have) a commit message describing what was done. This provides a clear history and makes it possible to go back to any version of the code base in the future.
Sometimes it’s worth experimenting — for example, turning a classic apple pie into an apple tart. Without changing the original recipe, you can create a variation of it, using the recipe as a base. In Git, it is branching that allows you to try out new coding ideas without disturbing the underlying code base. If, after testing the recipe, you are satisfied with the result, you can add the changes to your cookbook….
In Git, a branch is a separate line of code development. It allows you to work on a new feature or fix it without affecting the main or “master” branch. Once the changes in a branch are tested and completed, you can merge them back into the master code base.
Your apple tart turns out great. So much so that you decide to add it to the main cookbook alongside the classic pie. For that, you might want to first introduce the changes (create a pull request) and after this addition to the cookbook gets approved, it can be implemented into it. In the Git world, if the part of the code is ready to be added to the main code, you create a pull request, which gets reviewed. If it meets acceptance criteria, it gets integrated with the main code.
A pull request is a proposal to merge changes from one branch to another, often used in collaborative projects to review, discuss and then incorporate changes into code.
Now imagine that your cousin loves your cookbook, but wants to add vegan alternatives and a section on smoothies. He decides to create his version of the cookbook, inspired by yours. This act is like a fork in Git, where you base your project on someone else’s, but add your unique twists.
Forking in Git is creating a personal copy of someone else’s project. It allows you to freely experiment with changes without affecting the original. Often, after making improvements to the fork, contributors can propose changes back to the original repository.
While working on recipes together with your friend, he has added new recipes to the main cookbook, which includes a new vegan spaghetti recipe. Of course, you want to work with the latest version of the cookbook, for example, to make sure you’re not duplicating recipes. Similarly, in Git, pulling changes means making sure you’re working with the latest version of your code, integrating any new updates or improvements.
In Git, pulling means downloading the latest changes from an online repository to your local computer. This ensures that you are always working with the latest version of your project, integrating updates or improvements made by others.
Hope you liked a quick story about a cookbook. If the concept of git is still a bit blurry, I can recommend this simple online game, which one of my colleagues showed me some time ago.
Let me know if there are any other git analogies that are coming to your mind — I will be happy to list them here! :)
— — — —
If you feel like discussing this further, drop me a line at:
So much fun to talk to other data geeks!
