-
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. 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.
The copy of your code that is hosted on GitHub is known as the remote copy of your code. You will be making 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, and every change is 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 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.
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
Forks are a way for multiple people can contribute to one git project at the same time. 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 mainline. 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: