M1 Introduction to Git

NOTE: This is an extremely simplified guide to Git meant to kickstart your work in this course. We strongly recommend you read the Git Extended reading.

Git

Installation

Git may already be installed on your device. You can check this by running

git version

If it's not installed...

On your AWS Instance

# install git using the "yum" linux package manager
$ sudo yum install git

After installation, make sure you complete this final step

# Set the name and email for your git usage. 
# This does not have to match your GitHub account

# You can think of this as signing your name on your changes

$ git config --global user.name "<Your Name>"
$ git config --global user.email "<you@example.com>"

Why Git?

Git is a very powerful tool that's critical to modern software development. It's significance is rooted in three core features:

Distributed Version Control

Think of Git as a cookbook shared among several chefs. Each chef has a complete copy of the recipes, so they can all experiment and make changes without waiting for one another. If one chef spills sauce on their copy, the others are unaffected. Likewise, each chef can peek into each other's copies to see new recipes or changes.

In traditional centralized version control, there is a single "master" copy of the code. In contrast, Git's distributed nature means that every developer has a full-fledged copy of not only the entire codebase but also all the branches within it, including their respective histories. This structure allows more parallel development, supports experimentation with different parts of the code in isolation, and reduces reliance on a central server, thereby minimizing potential points of failure.

History and Tracking

Imagine your code as a time-traveling book where you can flip back to see what was written at any point in time. You can even find out who wrote each sentence and why.

Git keeps a detailed log of every change made to the code, including who made it and why (via commit messages). This allows for greater accountability and ease of tracking changes over time. If a bug is discovered, developers can quickly identify when it was introduced and by whom, facilitating a quicker resolution.

Branching and Merging

You can think of git branches as individual workspaces within a repository. Each branch allows for independent development, experimentation, or bug-fixing, and acts like a parallel universe to the main codebase. Changes made within a branch do not affect other branches, giving developers the freedom to explore and innovate without risk to the stable versions of the project. When a feature is completed or a bug is fixed, the branch can be merged back into the main codebase, seamlessly integrating the updates.

Conflict Resolution

Without Merge Conflicts

Imagine two developers working on two new features, each in their own branch. If both developers are working on different parts of the codebase, or different files altogether, their changes can typically be merged back into the main codebase without any conflicts. The modifications are independent of each other and do not overlap, allowing for a seamless merge.

With Merge Conflicts

Now consider a scenario where both developers are working on the same part of the code or the same file within their respective branches. When they try to merge their changes back into the main codebase, there may be conflicts where their changes overlap. Git will not know which changes to keep and which to discard, leading to a merge conflict.

In this situation, manual intervention is needed to resolve the conflicts. The developers must review the conflicting changes, decide which to keep or how to combine them, and then commit the resolved code. Command line tools and graphic interfaces (likely built into your IDE) can assist in this process, but understanding the context of the changes and clear communication between developers is crucial for a successful resolution.