Git and GitHub Overview

Git is a free and open-source distributed version control system.

Install git and create a GitHub account

  • more about how to install git – here. There is a GUI option to use git, but I would recommend start (and probably stick with CLI)
  • Create GitHub account here

install git in Linux:

sudo apt install git-all

Set your user name and email address

every Git commit uses this information, and it is been added into the commits you start creating:

git config --global "Dmitry Golovach"
git config --global

Create a local git repository (project folder)

mkdir sandbox
cd sandbox
git init

Initialized empty Git repository in /home/cisco/sandbox/.git/

The idea: make changes in the repository, if it is in the state we want to record – commit.
Each file in the working directory can be in one of two states (check the status with git status command):

  • tracked
    • git knows about these files
    • can be unmodified, modified, or staged
  • untracked
    • everything else

The idea: change files – selectively stage these modified files and then commit all those staged changes

Once we add a new file – it will be untracked (it is new and uknown for git), but git recognizes that new file was added:

Staging environment – git add

To add a file to a commit, we first need to add it to the staging environment using git add command:

Commit – git commit

Now files are ready to commit using git commit -m “message” command. It’s good to add a comment about what has been changed in this commit.

If we need to keep track of own code locally – don’t need to use GitHub. But it is always good to have a copy of repository somewhere else or for work in team => GitHub

GitHub – git push

Create a new repository and you can keep it Private (later change it to Public) or Public:

Quick notes how to work with GitHub:

push the commit in your branch to your new GitHub repo.

Note: if you have 2FA enabled (you probably should), follow the “Creating a personal access token for the command line” to use a Personal token as a password:

git remote add origin
git push -u origin master

As result files have been pushed to the GitHub:


Work with repository and files, once done

#Add the file to your local repo. Files are ready to be committed
git add <filename>

#Remove from staging (unstage)
git reset HEAD <filename>

#Commit the tracked changes. Files are aready to be pushed to remote repo
git commit -m "message"

#Remove commit and modify the file
git reset --soft HEAD~1

#Push the changes in your local repo up to the remote repo
git push -u origin master

Git commands:

  • git clone <url> : take a repository stored on a server (like GitHub) and downloads it
  • git add <filename(s)> : add files to the staging area to be included in the next commit
  • git commit -m "message" : take a snapshot of the repository and save it with a message about the changes
  • git commit -am <filename(s)> "message" : add files and commit changes all in one
  • git status : print what is currently going on with the repository
  • git push : push any local changes (commits) to a remote server
  • git pull : pull any remote changes from a remote server to a local computer
  • git log : print a history of all the commits that have been made
  • git reflog : print a list of all the different references to commits
  • git reset --hard <commit> : reset the repository to a given commit
  • git reset --hard origin/master : reset the repository to its original state (e.g. the version cloned from GitHub)

More on Git

  • ‘Branching’ is a feature of Git that allows a project to move in multiple different directions simultaneously. There is one master branch that is always usable, but any number of new branches can be created to develop new features. Once ready, these branches can then be merged back into master.
  • When working in a Git repository, HEAD refers to the current branch being worked on. When a different branch is ‘checked out’, the HEAD changes to indicate the new working branch.
  • When merging a branch back into master, there is the possibility for merge conflicts to arise. These can be resolved in the same way discussed in Lecture 0.
  • Some Git commands related to branching:
    • git branch : list all the branches currently in a repository
    • git branch <name> : create a new branch called name
    • git checkout <name>: switch current working branch to name
    • git merge <name> : merge branch name into the current working branch (normally master)
  • Any version of a repository that is not stored locally on a device is called a ‘remote’. ‘Origin’ is used to refer to the remote from which the local repository was originally downloaded from.
  • Some Git commands related to remotes:
    • git fetch : download all of the latest commits from a remote to a local device
    • git merge origin/master : merge origin/master, which is the remote version of a repository normally downloaded with git fetch, into the local, preexisting master branch
      • Note that git pull is equivalent to running git fetch and then git merge origin/master
  • A ‘fork’ of a repository is an entirely separate repository which is a copy of the original repository. A forked repository can be managed and modified like any other, all without affecting the original copy.
  • Open source projects are often developed using forks. There will be one central version of the software which contributors will fork and improve on, and when they want these changes to be merged into the central repository, they submit a ‘pull request’.
  • A pull request can be made to merge a branch of a repository with another branch of the same repository or even a different repository. Pull requests are a good way to get feedback on changes from collaborators on the same project.
  • Note that forks and pull requests are both GitHub specific features.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *