Seamonsters-2605.github.io

Learning Git

We will be practicing Git today. Git is “version control” software—it remembers the history of all of your code files, and it lets you synchronize changes to code with multiple team members working at once.

A Git repository holds all the files for your project. GitHub is a website that hosts Git repositories online, so anyone can download the files and contribute changes from anywhere.

To practice Git you will start by making your own personal repository on GitHub.

You have a public repository now! It’s availible for anyone to view at github.com/your-name/your-repository-name. You’ll see a list of files—right now there’s just one, README.md where you can put information to introduce your project.

Now you are going to clone the repository to your computer. This not only downloads all the files, but links them with Git to the repository on GitHub, so any changes you make can be “pushed” online and “pulled” back to your computer.

If it worked you should see something like this:

Cloning into 'test-repository'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.

Notice that README.md is highlighted in red and listed under “Untracked files”. This means that the file has been modified with changes that haven’t been saved in the repository yet.

Git keeps track of the history of the repository in the form of commits, which are discrete changes to the files in your repository. Since you have modified README, you need to commit your changes to make them a permanent part of your repository.

Type git status again. You will see a different message. README is no longer listed, because all changes to it have been committed. But now it says: Your branch is ahead of 'origin/master' by 1 commit..

This means that although you have made the commit on your computer, it isn’t online on GitHub yet. Nobody else can see the changes you made, and if your computer breaks they will be lost forever. You can fix this by typing git push. (you’ll need your GitHub username and password).

Once this has finished successfully, in your web browser refresh the page for your repository. You’ll see everything you added to the README file on the front page. And if you click the text that says “2 commits,” you can see the history of all the changes you made, which so far is only 2 commits long (the first was automatically made by GitHub when you created the repository).

Now try adding another file! It can be written text, a Python file, or anything else (try to stick to plain text, Git works best with text). You can add, commit, and push this new file the same way you did with changes to README.

Branches

Branches are a powerful feature of Git. If you’re working on changes to the code that are experimental, not fully tested, or could potentially cause conflicts with other people’s work, you’ll want them on a separate branch. You can make commits to this branch without them affecting the main “master” branch. And commits to the “master” branch will not affect your branch, so you don’t have to worry about your code suddenly breaking.

You can imagine the series of commits you’ve made over the course of a project as points on a timeline, and branches as separate lines that branch off the main one. You actually don’t have to imagine this: GitHub will graph it for you! Here’s an example from last year’s competition code. Click and drag to scroll through it, and hover over the dots to see the commits.

When you are confident enough in your changes that you want them on the master branch, you can merge the branches together. The extra commits you made on the separate branch will be added to the master branch. Even if the master branch has been changed since you branched from it, Git will try to find a way to merge the changes together (and if it can’t, it will ask you to do it yourself).

Let’s practice branches:

In your web browser, refresh the page for your repository. You will still see the files from your master branch, without the new changes you made. But you can click the “Branch” dropdown to view a different branch. If you check your new branch you can see that the changes you made are there.

Now we’ll merge the changes back to the master branch:

Collaborating on a repository

Version control software like Git can do much more than just remember changes to your files. It can allow multiple people to collaborate on a single repository, by synchronizing those changes between people and resolving conflicts between the different versions.

I’ve created a repository that we can practice collaborating with: https://github.com/Seamonsters-2605/git-practice. Clone it to your computer (remember how to do that? check back in the document.) Practice adding/modifying files, committing, and pushing.

Pulling and resolving merge conflicts

With multiple people committing to this repository at once, we’re going to quickly run into problems. GitHub won’t let you push unless you have all of the existing commits from the repo. So if someone else made a change after you cloned the repo, when you try to push you’ll see an error message like Updates were rejected because the remote contains work that you do not have locally.

You can remedy this with the command git pull, which brings all the changes that others have made back to your local copy of the repository.

At this point Git will need to merge the changes that others made with the changes that you made. Git attempts to do this automatically, and is often successful (but not always). When Git merges two different versions of a file, it creates a new commit to unite the separate branches of history. It might open up a file in VS Code and ask you to enter a commit message. You can just close this file to keep the default message it generates.

If the merge was successful, you now should be able to git push.

More branches

To avoid conflicts like this, it’s best practice to create new branches for your changes. Look at the Branches section earlier in the document and try making some commits on different branches instead. Then try to merge your changes back to master.