Recounting my struggle with Git in pair programming
Yesterday, I started on my first student project that called for divergent versions— I decided that this was a great opportunity to utilize branches in git for the first time. In short time, I was forcefully made aware that it wasn’t as straightforward as expected. I want to share the challenges I encountered and how I came to a working (for me, at least) resolution.
Local vs. Cloud
Git and Github do not have a persistent stream of data between them. Only commands (such as push, pull, fetch) create that connection and trigger that data flow, and only in accordance to your request. Accordingly, you end up with two potentially divergent environments: local (as saved on your machine) and the cloud (as saved on Github).
The moment you write any code and save the file, your local and cloud versions have diverged. This may be obvious, but it’s an important concept to remember when you involve your pair’s local and cloud versions into the mix because things can get crazy for beginners (like me). I’ll explain.
Synchronizing your local data to match your pair’s local data isn’t like driving on a freeway — it’s more like driving through a small neighborhood; there might be a side street shortcut, or an alternate route altogether:
Git: Utilizing and managing branches made for your pair-programmed code
Those diagrams are already funky enough. When we add branches into it, complexity rises, with confusion on its tail. Rather than trying to sell you on implementing branches in your repo right away, I’d rather take the time to explain how I made this into less of a headache.
If you’re setting up fresh with your pair, and you’ll be working on code via your pair’s computer, you’ll want to set up your remote with them:
$ git remote add <remote_name> <git_URL>If you don’t understand how git remotes work, this is essentially saving whatever your pair’s .git URL is in the remote_name variable, so you don’t need to look it up each time you want to point to their repo. I’m not sure what the best practice is, but I name my remotes as I do my variables (usually my partner’s name or project’s title). With simpler access set up, we can work on creating a new branch:
$ git branch <branch_name> [<commit_hash_key>]By including a branch_name after branch, we’re choosing to create a new branch with that name within the directory that’s currently active. The optional hash key is if you’d like to clone the code state from the specified commit into the new branch. Keep in mind that all of these changes are local until we push to our repo (my confusion with this is pretty much the entire reason I wrote Local vs. Cloud). Now make sure that you stash or commit any modified file changes, and “switch” (more below) to the new branch:
$ git checkout <branch_name>Checkout not only switches us to the specified branch, but it also moves our local file system to that branch’s state. This means that any local changes you make while checking out in a branch will not affect your other branch’s files. This is key and bomb AF. If your pair has pushed their commits to the cloud, and you decide that you need to pull your pair’s code state to your local environment, try this:
$ git pull <remote_name> <remote_branch_name>Github: Utilizing and managing branches made for your pair-programmed code
:)