-
Notifications
You must be signed in to change notification settings - Fork 22
Part 1: Intro to Git
Git is a version control system for software development. GitHub is a website for sharing and making public projects that use git. Hosting a project on GitHub allows other people to contribute to your project. GitHub is not the only website that offers this; other such websites include BitBucket and GitLab.
Basically, git and GitHub makes it easy for many people to contribute to a coding project (or other project).
To explain with an example, the source code for the WiCS website is a public git repository. The repository contains all of the code and content we've written for the website, and all the history of every change we've ever made to it. The repository you are in right now is just a copy of the code there - minus the history of changes. We'll refer to the WiCS website as an example for the rest of the workshop.
In order to host a project on GitHub, you'll need a repository or "repo" for it to live in. Think of a repo as the folder that you keep your project in; it contains all the project files as well as any documentation.
Repos are either public or private. In a public repo, anyone can see the code you've written as opposed to a private repo that is, well, private. For example, many people host the code that runs their personal sites in a public repo because they want potential employers to be able to look at the code they've written. However, if you ever host a class project on GitHub, for example your CS246 final project, you will want to host it in a private repo to avoid academic offences.
GitHub saves a copy of your project in the GitHub framework, this is known as the "remote" of your repository. However, you cannot modify this copy directly.
You will have to make a copy of this code on your own computer, so that you can view and edit all the files. This will be the "local" of your repository.
Committing is how you make changes to content in a git repo similar to "saving" changes you make to one or more files in your project. Every time you make a commit, Git generates an ID (known as the "SHA" or "hash") for that commit so that you can identify it later. There are a few other steps to make your commit affect the project, but we'll go into that later.
All commits are saved in the Commit History; this is one of the many differences between a git repository and a regular directory.
Having a commit history is super useful because:
- It gives you the ability to return to the state of your (local or remote?) repository before a specific commit
- It shows you which commits break which things
- It shows you how the repo evolved with each change
You can poke around the commit history of this repo, by going to code tab > commits, or the much more interesting commit history of the WiCS website repository.
The actual internals of how git handles this are more complicated than the scope of this workshop. However, you can learn more about it here and also other places on the internet.
You will notice when you navigate to the code tab for any repository, you can view the branches for that repository. Our repo has 1 branch: master. Every git repository comes with a master branch, you can think of this as the "main" branch of your repo, this is the actual code that is running the website.
When you make a "branch off of master" you are creating a new and separate commit path, that has all the commits that master does at the time of creation. Any changes on this branch will not affect your master branch unless you merge the branch back into master.
Branches can be used for:
- Developing a feature without affecting any of your working code
- Testing new features
- Saving the state of your repo at a particular time
Imagine what a nightmare it would be if several people were working on the same branch at the same time -- what a nightmare!
Forks are a way for multiple people can contribute to one git project at the same time without messing anything up or getting confused. Having "a fork" of a repo means that you have a copy of a public repository that you treat as your own. To contribute back to the main repository, the main repository merges in changes from the developer's remote fork. Forks are a concept that exist outside of git itself, but they are still useful. In GitHub, developers submit pull requests when they want to merge their fork into the master branch. In GitLab, they are called merge requests. They're the same thing.
All of the people who contribute to the WiCS website have a fork of the site. You can see my fork of the website here. As you will notice, my fork is (hopefully) up to date with the WiCS website repo. The two master branches should have the same content and same commit history, until either branch has a change made. If I make a change to my fork, I make a pull request to merge in into the WiCS website. If someone else makes a change to the WiCS website, I update my fork to match.
As you can see in the you will be forking this repo and making changes and submitting pull requests to it.
To get started actually doing things, click the following links based on the kind of machine you have: