By: Andrew Haberlandt and Adam Lis
A “repository” consists of two parts:
.git/
folder (don’t touch!), Git tracks the history of all your files(Note: This is a simplification. If you take CSE 3901/3902/3903 you will study Git in more detail.)
A “history” is a graph of commits. A commit (noun, also known as a “revision”) is a set of changes to files in your repository, accompanied by a message describing the changes. Here’s an example commit on GitHub.
A commit (except for the first) always has at least one parent - thus you can always trace any commit back to the single “initial” commit in any repository. So, you can see all of the changes that lead up to the current state.
A commit will always be on a particular branch - you can think of branches as multiple independent (but connected) parts of your “history” - this is useful if you are simulataneously working on multiple features on the same project. The default branch in Git is the master
branch.
“commit” is also used as a verb - meaning the act of creating a commit from your local changes (we’ll use this in Part 4)
If everyone just pushed to the master
branch, you might have a purely linear history:
[master]
|
* -----> * -----> * -----> *
A B C D
But in reality, you have multiple people working on multiple different features – they will use different branches that can be merged together as features are finished:
* -----> * -----> * -----> * -------> * [master]
A \ C / E \ F \ I
\ / \ \
* ------> * \ * -----> * [feature-2]
B D \ H J
\
\
* [feature-1]
G
This entire graph is stored in the “history”.
Your local computer and the server (We use GitHub, but there are many services) might have differing histories. To sync our history with the history stored by the server, we will use two operations:
You will never be able to directly push to master. Therefore, before pushing your code you will have to checkout a new local branch (this is covered in the later parts of this tutorial.)
Since we’re using VS Code’s Git interface, we won’t perform push and pull operations directly. Instead, we’ll click the “sync” button which performs a Git Pull and then a Git Push.
Git has a nice command-line interface, but for the purposes of this tutorial we will be using the interface in Visual Studio Code.
Open Visual Studio Code, and open a new window (File -> New Window)
Select the “Git” menu.
Choose “Clone Repository”
Choose “Clone from GitHub” and complete the one-time authentication process
You should then be able to type “code4community/” and get a list of all repositories in our organization!
After the clone is complete, you will see the the following in the lower-right:
You likely want to choose “Open” if you followed the instructions closely, since you already have an empty window.
You should see the files for the repository, as shown in the below screenshot:
Congratulations! You succesfully cloned our repository!
You can also view the repository for this tutorial on GitHub here. All of our repositories are available on our organization GitHub page.
Find the repository location in your operating system’s finder/explorer, and open index.html in your web browser of choice. You should see the following (with the images moving around the screen):
Goal: Add yourself to our display of bouncing heads
By default, when you clone a repository, Git checks out the master
branch. On your local machine, you can commit to the master branch. However, we have configured GitHub to refuse pushing to the master
branch directly.
Why? It’s because for all of our projects, you will be pushing to separate branches for each feature you work on. You will then create a pull request in GitHub, requesting that your peers review your code before it gets merged into the master
branch.
Give your branch a unique name. For the purposes of this tutorial, just use your name.#
Verify in the bottom bar that your new branch name is displayed instead of “master”.
Add an image to the images/
directory. You can drag-and-drop from the file explorer on your operating system directly into VS Code.
Note: Your image does not have you be an actual picture of yourself, although it might help us learn each other’s names.
Things to note:
U
ntracked - we haven’t told Git to track changes to this file yet. The file is brand-new and has no history.Switch to the Git pane, and you’ll see only the files with changes in your working copy.
Now, you should see:
Note: the “U” next to the image has changed to an “A” for A
dded, now that we have added this file to Git.
Add a commit message (this should briefly explain your changes):
Press the checkmark:
Look in the bottom bar. You should see something like this (it will say your branch name rather than brutus.1):
Press the cloud with an upward arrow. This pushes your changes to GitHub.
If you pull up the repository in a browser, you might see the following (with your branch name):
If so, you can click “Compare & Pull request” and it save you a few clicks.
Otherwise:
You’ll see something like this:
So,
For this repository, you need at least two approvals before you can merge your pull request into master.
Request your reviews here:
Please review multiple pull requests so everyone can merge their PR :)
Hopefully, you now have two approvals on your PR
If not, you’ll see this:
If so, you’ll see this:
If you have two approvals, click the big green merge button!
Now you should be able to see your changes live on https://code4community.github.io/git-tutorial/!
If you have any feedback for this tutorial, please create a GitHub issue or talk to one of the leaders of C4C.