Git Demystified for Non-programmers Part Two

At the June, 2016 meeting, Jimmy Cuadra gave the second half of his presentation about the Git version control system. This meeting was summarized by Pete Babb.

While part 1 was an overview of how Git is set up and the basics of commits, part 2 covered Git’s key features: Branching, merging, and collaboration. These functions work via the HEAD reference, which points to the commit you are working on. Any changes you make are applied to the commit the HEAD is pointing at, and you can look at an earlier commit by having the HEAD reference point to it. Making and merging branches is a quick process in Git because of the pointer system, whereas they could take hours in older systems.

Branches silo changes, keeping your main document intact while you try out an idea. Git creates branches by creating a second pointer that points at a commit, and as you make new commits, that second pointer makes them an offshoot of the main trunk. If, after trying out your idea, you decide you like it and want to keep it, you would then merge that branch back with the main trunk.

For example: You’re working on your Master branch and you have an idea you want to try, but you don’t want to alter your Master. You would create a branch (call it “New Idea”) that the HEAD now points to. Now, when you do a commit, the Master branch is no longer affected, as new commits are applied on the New Idea branch. At any point, you can abandon New Idea and go back to working on the Master by making HEAD point to the Master branch again.

If you decide you like New Idea and want to integrate it back into the Master branch, you would use the merge command, which puts the New Idea branch’s latest commit in the Master branch. This is quick and easy as long as the Master remained unchanged while you were working on the New Idea branch.

However, if the Master was altered while the New Idea branch was being worked on and the two branches made different changes to the same thing, you will have a merge conflict. In this case, Git will ask for user intervention to decide which changes to keep. Thus, communication is paramount: All team members need to know what the conflict is so that the team can decide which changes to keep.

Distributed Git is for sharing work with remote team members. It gives each member the whole repository so they can work in their own sandbox. This way, the individual repositories don’t affect each other, so each team member can work independently, and then the work can be brought together via the merge command.

While Git is a very powerful tool, it does not eliminate the need for people to communicate. It’s easier than older version control systems, but people still have to make decisions about which changes to make final. As such, it should be seen as an enhancement to collaboration, not a replacement for it.

The biggest user tip, though, is to not try to learn all of Git or try to remember every single command. It’s a massive system that has a lot of functions writers simply will not need, so it’s more important to absorb general ideas and workflow. The best way to learn it is to use it and pick up on new functions as you need them.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s