Git & GitHub
Compiled by inTech
At a high level, GitHub is a website and cloud-based service that helps developers store and manage their code, as well as track and control changes to their code. Version control helps developers track and manage changes to a project’s code. As a project grows, version control becomes essential.
Git VS. GitHub
GitHub is a company that offers a cloud-based Git repository hosting service on the web, making it easy for individuals and teams to use Git for version control & collaboration. Alternative hosting services are: BitBucket and GitLab.
On the other hand, Git is a distributed version control system that allows developers to track and manage changes to a software project’s codebase. Often times, those that do not know about GitHub end up saving their project to Google Drive and attempting to collaborate through those means, but Google Drive doesn’t have version control like Git does.
Glossary
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.
Commands
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
Remote
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
Meetings
We have a GitHub workshop almost every semester. You may need to be signed in with your Broward College Zoom account in order to access the link. Sign in with SSO.
Ideal Branch Structure
When dealing with branches, it is important to have a consistent naming convention. Below is an ideal structure.
main > dev > developer’s name / feature
Here is an example:
main > dev > bobby/main-menu
The most stable version of a project repo should be the “main” branch. The dev/development branch should be the branch that represents the most fully-featured branch that may include bugs. The branches that stem from “dev” are the branches that individuals actively work in.
Step by Step Guides
There are several ways of utilizing the functionalities that Git has. You could either use a graphical user interface (GUI) or use the command line. Another common usage is using Git through Visual Studio Code. Since command line is most used in the industry, we are demonstrating that method most of the time in these guides.
Beginner Guide to Starting a GitHub Project
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.
Common Workflows
Provided below is a series of commands that will often happen while you are working on a repository.
Everyday Git Commands
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
Can't Checkout Branch
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