Understanding Git & Github

Git

I honestly had no idea about Git & Github when I started my journey in the programming world. At first, I thought they were computer languages like Java & JavaScript. Quickly I realized that they are being used for version control system designed to handle everything from small to very large projects.

What’s Git?

By far, the most widely used modern version control system in the world today is Git. The major difference between Git and any other VCS is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as delta-based version control). Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots

Why Git?

Git is commonly used for both open source and commercial software development, with significant benefits for individuals, teams and businesses.

• Git lets developers see the entire timeline of their changes, decisions, and progression of any project in one place. From the moment they access the history of a project, the developer has all the context they need to understand it and start contributing.
• Developers work in every time zone. With a DVCS like Git, collaboration can happen any time while maintaining source code integrity. Using branches, developers can safely propose changes to production code.
• Businesses using Git can break down communication barriers between teams and keep them focused on doing their best work. Plus, Git makes it possible to align experts across a business to collaborate on major projects.

Basic Git Commands

git init

This command turns a directory into an empty Git repository. This is the first step in creating a repository. After running git init, adding and committing files/directories is possible.

Usage:

# change directory to codebase
$ cd /file/path/to/code
# make directory a git repository
$ git init

In Practice:

# change directory to codebase
$ cd /Users/computer-name/Documents/website
# make directory a git repository
$ git init
Initialized empty Git repository in /Users/computer-name/Documents/website/.git/

git add

Adds files in the to the staging area for Git. Before a file is available to commit to a repository, the file needs to be added to the Git index (staging area). There are a few different ways to use git add, by adding entire directories, specific files, or all unstaged files.

Usage:

$ git add <file or directory name>

In Practice:

# To add all files not staged:
$ git add .
# To stage a specific file:
$ git add index.html
# To stage an entire directory:
$ git add css

git commit

Record the changes made to the files to a local repository. For easy reference, each commit has a unique ID.

It’s best practice to include a message with each commit explaining the changes made in a commit. Adding a commit message helps to find a particular change or understanding the changes.

Usage:

# Adding a commit with message
$ git commit -m "Commit message in quotes"

In Practice:

$ git commit -m "My first commit message"
[SecretTesting 0254c3d] My first commit message
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 homepage/index.html

git status

This command returns the current state of the repository.

git status will return the current working branch. If a file is in the staging area, but not committed, it shows with git status. Or, if there are no changes it’ll return nothing to commit, working directory clean.

Usage:

$ git status

In Practice:

# Message when files have not been staged (git add)
$ git status
On branch SecretTesting
Untracked files:
  (use "git add <file>..." to include in what will be committed)
  	homepage/index.html
# Message when files have been not been committed (git commit)
$ git status
On branch SecretTesting
Your branch is up-to-date with 'origin/SecretTesting'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
        new file:   homepage/index.html
# Message when all files have been staged and committed 
$ git status
On branch SecretTesting
nothing to commit, working directory clean

git config

With Git, there are many configurations and settings possible. git config is how to assign these settings. Two important settings are user user.name and user.email. These values set what email address and name commits will be from on a local computer. With git config, a — global flag is used to write the settings to all repositories on a computer. Without a — global flag settings will only apply to the current repository that you are currently in.

There are many other variables available to edit in git config. From editing color outputs to changing the behavior of git status. Learn about git config settings in the official Git documentation.

Usage:

$ git config <setting> <command>

In Practice:

# Running git config globally
$ git config --global user.email "my@emailaddress.com"
$ git config --global user.name "Brian Kerr"
# Running git config on the current repository settings
$ git config user.email "my@emailaddress.com"
$ git config user.name "Brian Kerr"

git branch

To determine what branch the local repository is on, add a new branch, or delete a branch.

Usage:

# Create a new branch
$ git branch <branch_name>
# List all remote or local branches
$ git branch -a
# Delete a branch
$ git branch -d <branch_name>

In Practice:

# Create a new branch
$ git branch new_feature
# List branches
$ git branch -a
* SecretTesting
  new_feature
  remotes/origin/stable
  remotes/origin/staging
  remotes/origin/master -> origin/SecretTesting
  
# Delete a branch
$ git branch -d new_feature
Deleted branch new_feature (was 0254c3d).

git checkout

To start working in a different branch, use git checkout to switch branches.

Usage:

# Checkout an existing branch
$ git checkout <branch_name>
# Checkout and create a new branch with that name
$ git checkout -b <new_branch>

In Practice:

# Switching to branch 'new_feature'
$ git checkout new_feature
Switched to branch 'new_feature'
# Creating and switching to branch 'staging'
$ git checkout -b staging
Switched to a new branch 'staging'

git merge

Integrate branches together. git merge combines the changes from one branch to another branch. For example, merge the changes made in a staging branch into the stable branch.

Usage:

# Merge changes into current branch
$ git merge <branch_name>

In Practice:

# Merge changes into current branch
$ git merge new_feature
Updating 0254c3d..4c0f37c
Fast-forward
 homepage/index.html | 297 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 297 insertions(+)
 create mode 100644 homepage/index.html

Working with remote repositories

git remote

To connect a local repository with a remote repository. A remote repository can have a name set to avoid having to remember the URL of the repository.

Usage:

# Add remote repository
$ git remote <command> <remote_name> <remote_URL>
# List named remote repositories
$ git remote -v

In Practice:

# Adding a remote repository with the name of beanstalk
$ git remote add origin git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git
# List named remote repositories
$ git remote -v
origin git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git (fetch)
origin git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git (push)

Note: A remote repository can have any name. It’s common practice to name the remote repository ‘origin’.

git clone

To create a local working copy of an existing remote repository, use git clone to copy and download the repository to a computer. Cloning is the equivalent of git init when working with a remote repository. Git will create a directory locally with all files and repository history.

Usage:

$ git clone <remote_URL>

In Practice:

$ git clone git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git
Cloning into 'repository_name'...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 5 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (5/5), 3.08 KiB | 0 bytes/s, done.
Checking connectivity... done.

git pull

To get the latest version of a repository run git pull. This pulls the changes from the remote repository to the local computer.

Usage:

$ git pull <branch_name> <remote_URL/remote_name>

Github

What is Github?

GitHub is a Git repository hosting service. It takes that change history made by you so far in your code and hosts it online so that you can access it from any computer. You do this via pushing changes from your terminal up to Github, and then, from the new/different computer pulling those changes down.

Why Github?

GitHub builds collaboration directly into the development process. Work is organised into repositories, where developers can outline requirements or direction and set expectations for team members. Then, using the GitHub flow, developers simply create a branch to work on updates, commit changes to save them, open a pull request to propose and discuss changes, and merge pull requests once everyone is on the same page.

Github Flow

The GitHub flow is a lightweight, branch-based workflow built around core Git commands used by teams around the globe — including ours.

The GitHub flow has six steps, each with distinct benefits when implemented:

1. Create a branch: Topic branches created from the canonical deployment branch (usually main) allow teams to contribute to many parallel efforts. Short-lived topic branches, in particular, keep teams focused and results in quick ships.
2. Add commits: Snapshots of development efforts within a branch create safe, revertible points in the project’s history.
3. Open a pull request: Pull requests publicize a project’s ongoing efforts and set the tone for a transparent development process.
4. Discuss and review code: Teams participate in code reviews by commenting, testing, and reviewing open pull requests. Code review is at the core of an open and participatory culture.
5. Merge: Upon clicking merge, GitHub automatically performs the equivalent of a local ‘git merge’ operation. GitHub also keeps the entire branch development history on the merged pull request.
6. Deploy: Teams can choose the best release cycles or incorporate continuous integration tools and operate with the assurance that code on the deployment branch has gone through a robust workflow.

If you want to learn more, you can view the handbook over here.

Thanks for reading!