Collaboration with Git (1): The Structure of Git

Coding doesn’t always flow as smoothly as you’d like it to, which is why managing your source code is super important. While working, you might find yourself switching from one unfinished module to another feature, or suddenly get hit by a wave of inspiration that flips everything upside down. Coding is a lot like writing — it’s a cycle of ‘write,’ ‘rewrite,’ and ‘write again.’ 🖋️

There’s this ancient Chinese poet who pondered over the perfect word choice — should it be ‘push’ or ‘knock’? This gave birth to the term ‘editing.’ Personally, I’d pick ‘push’ without a second thought, but apparently someone else suggested ‘knock.’ While that debate isn’t crucial here, it highlights how we constantly refine our code as well. 💭

That’s why, while coding, it’s a good idea to create a snapshot whenever you reach a natural stopping point. If you end up disliking the changes later, you can always roll back to that snapshot. This is known as version control, and Git has largely replaced older systems like SVN. The standout feature of Git is its distributed nature for managing code.

Let’s dive into Git’s structure. On a developer’s local machine, the Working Directory is where the physical source code is stored. It’s the space you see with your file explorer, where files actually live. When you save in a development tool, it gets saved here. Without a version control system, this would be your only space. In the Working Directory, saving overwrites previous versions. Applying Git creates a Staging Area and a Local Git Repository, where snapshots are stored via a process called Commit. To revert to a previous state, you’d check out from the Local Git Repository. The Staging Area is for temporarily saving work that isn’t ready to be committed yet. (In some coding tools, this area might not be explicitly visible.)

The Remote Git Repository is your safety net, ensuring you can recover your code even if your laptop crashes. It’s also the hub for exchanging code in collaborative projects. Pushing sends code from your Local Repository to the Remote Repository, while Pulling retrieves code in the opposite direction. But technically, the opposite of a push is a fetch, which pulls code to the Local Git Repository. Usually, we pull because we intend to continue working, so it updates the Working Directory too. GitHub (github.com) is a well-known provider of these remote repository services. 🌐

When collaborating, it’s crucial to designate a clear source master. To work together, you start by getting the source from the master (base repository). This is a fork operation, happening between remote servers, where you grab the latest commit version of the branch, known as the head. (Technically, the head points to the last commit of the branch.)

From here, the process mirrors individual work. You bring the forked version into your Working Directory and complete your assigned tasks. Once done, push your changes to your Remote and send a pull request to the server you forked from. The master then checks for issues or conflicts before merging it into the base repository.

While it sounds simple, real-world collaboration requires guidelines and finding the best practices along the way. Clearly defining branches for forks and pull requests is essential to avoid confusion, and excessive pull requests should be avoided. However, the right guidelines may vary based on the project’s nature, collaboration model, and developers’ skills. 🤝

What’s truly important is not just talking the talk but actually walking the walk, right? 😉

Next, we’ll explore how to collaborate using Xcode’s Source Control menu. Stay tuned! 🔧