Git & GitHub

When you are listening in to workshops or discussions surrounding software development projects, there are a lot of terms that get thrown around. We have created this glossary to define those terms as well as terms specific to version control.

Version Control

The practice of tracking and managing changes to software code. This allows for the developer to recall specific versions of the code. Having version control is great for collaborative projects.

Repository

A project that is located on a computer. More technically, it is a central file storage location that version control systems use to store multiple versions of files.

Local

Anything to do with the version of branches/repositories located on a local computer.

Remote

Anything to do with the version of branches/repositories located on a remote computer.

Repo/Repository

A central file storage location that version control systems use to store multiple versions of files.

Deployment Environments

What this refers to is the environment in where a codebase is being deployed. Examples of different environments include Local, Development, Testing, Staging, and Production.

Development Environment

This is where changes to the software or codebase are developed, such as an individual developer's workstation.

Staging Environment

This is also known as a pre-production environment. This is a testing environment that essentially exactly resembles the production environment. It is used to test everything before it is applied to the production.

Production Environment

This is also known as a live environment. This is the environment that users will interact with directly.

Staging Area

The collection of files that are going to be part of the next commit

Tracked vs Untracked Files

Tracked files are files that git knows of and maintains a history of, while untracked files are files that git has no knowledge of.

Upstream

Relates to the remote repository.

e.x: Pushing changes "upstream" means uploading the changes.

Downstream

Relates to the local repository.

e.x: Pulling or fetching changes "downstream" means downloading the changes from the remote repository.

Branching

In Git, branching allows for different developers to work on the same project without disrupting each other's work. With branching, multiple features can be worked on concurrently. This command allows you to view all the different branches in your repository. $ git branch

Merging

Combining the work done on two or more branches. $ git merge branchname

Fetch

The act of downloading the changes made from the remote repository without affecting the work done on the local version. $ git fetch

Pull

The combination of the "merge" and "fetch" commands. This retrieves the changes made from the remote version of a vranch and merges them with the local version.

Note: If all you want to do is preview an update to a branch, use the "fetch" command.

$ git pull

Add

Place or mark file(s) worked on within the local branch to the "staging area" This command adds random.py to the staging area. $ git add random.py This command adds all untracked files to the staging area. $ git add .

Commit

Finalize the files that were worked on. It is customary to have a message assigned to every commit that is made. $ git commit -m "This is a message."

Push

Update the remote branch with committed changes from a local version of the branch. $ git push This command in particular specifies which branch you are pushing changes to. $ git push origin mybranch/feature

First things first, create an account on GitHub.

Second things second, download Git to your computer.

1. Create a repository on GitHub.

   You can do this by looking at your dashboard and clicking the green button that says "New", or looking at your navigation and clicking on the plus sign.

   You can simply enter the name of the repo, make it public, and click "Create repository".

2. Now let's focus on your local environment. Navigate to where you want to place your project.

   For instance, on your desktop, or in the root of a personal projects folder. You can enter the location either through command line or using a file explorer.

   If you entered using the file explorer, right click anywhere in the root of your location and click on "Git Bash Here".

3. Initialize your repository in this location. $ git init
4. Now go back to your GitHub repository that you created in Step 1. If you click on the green "Code" button, you will see an HTTPS link. Copy this link, and type out the following command: $ git clone https://github.com/youruser/reponame.git

   The clone command simply copies the remote repository into your local repository.

5. Create a new branch and enter it. $ git checkout -b you/feature

   The "-b" flag is used to create a branch. If you want to simply travel to another branch, you would simply use "checkout" and the name of the branch.

   If you would like to see all of the branches in your local repo, you would use this command:

   $ git branch
6. Populate some kind of file or document, either by using a command, using a code editor, or manually adding it. $ touch random.py

   The touch command creates files. For more information on basic commands, visit this page. Oh wait, there isn't a page yet.

7. Create and configure your .gitignore file to be global. $ touch ~/.gitignore $ git config ``global core.excludesFile ~/.gitignore
8. Check your staging status to see what files have been added and tracked. $ git status
9. Add your changed files to your staging area. You can either add individual files, or you can add all files using just a dot. $ git add . $ git add random.py
10. Commit staged files with a message to take note of the changes that were made. $ git commit -m "You did a thing!"
11. Push your commit to the remote repository.

    Since this is the first push that you are making to the remote repository, you first have to run the following command:

    $ git remote add origin https://github.com/youruser/reponame.git

    From then on, this is the command you will be using to push your commit.

    $ git push origin you/feature

    You should specify which branch you are pushing your changes to.

For the most part, these are probably going to be your most-used commands.

1. Luis logs into his computer to start the project. He must make sure that he has the updated project from the remote repository. $ git pull
2. Luis starts working on the project. He is working in the main-menu/luis branch. Luis created the overall structure of the menu so far, so he decides to make a commit. $ git add . $ git commit -m "Created structure of the menu."
3. Luis adds in the functionality of linking items within the menu. He decides to commit again. $ git add . $ git commit -m "Added links to items in the menu."
4. So far so good. The menu works, but Luis decides he wants to add some styling, and then that will be it for the day. $ git add . $ git commit -m "Styled the menu to be more aesthetically pleasing." $ git push

Sometimes, you can't checkout to another branch because the current branch you're in has untracked files. The terminal will tell you to either stage those files or to stash them. The "git add" command will allow you to stage these files, but sometimes you might not want to stage them. So, you would run one of the following commands:

• This command will forcefully clean out all the files that are being tracked. $ git clean -f -d
• This command will temporarily "shelve" changes you've made to the branch so that you can work on another branch. $ git stash