Git Introduction

Bill Doyle’s Gentile Introduction to Git

These are my notes from Bill Doyle’s lecture about Git. They lack the board illustrations and only record the salient points that Bill made about Git.

  • Using Git is like crtl-z or crtl-y in a text editor or word processor. It lets you move back and forth in time or versions of your document.
  • Versions are snap shots of your work that you have made in your document.
  • You make commits in Git to make snapshots or versions of your file.
  • Actually before you commit, you first have to add the file to Git’s staging area.
  • But Git does more then crtl-z and crtl-y. It keeps versions of all the files in a directory structure.
  • But Git does even more. It lets you make branches which allows you to to try several alternatives simultaneously. You can then decide what version you like better.
  • Using different branches, your teammates can work on different features of your project.
  • If you want to combine a versions from one branch to another branch then that is called merging a branch.
  • Most of the time that you merge two branches Git does it automatically without any help or problems.
  • Sometimes Git cannot merge automatically because the two versions have changes on the same line in a file. This is called a merge conflict.
  • If there is a merge conflict then it aborts the merge and creates a new version of the file that caused the merge conflict.
  • When you look into the file, you will see code from both versions of the file. The file is just a text file so you can delete the text you don’t want and even add text. You can then do the commit again, and Git will be happy and complete the commit.
  • Remember that merges conflicts just generate text files, so do not be afraid of them.

Robert’s Lecture about Basic Git

Tools

There many tools that come with Git or are built on top of Git. Most IDE have Git built into them. Do not use the tools in the IDE them. They use different terminology and they do not have all the features of Git. You won’t know exactly what you are doing, and I cannot tell you what to do.

Use the tools that come with Git:

  • Git GUI
  • Git Bash

Git GUI is a graphical interface. Git Bash is a command line interface (CLI). With a little experience, it is just as fast as Git GUI and lets you do more. This lecture is about Git Bash.

What makes Git different then other Version Control System (VCS) is that it has two parts, a Git Local and a Git Distributive. This means that you have a local repository and a remote repository, and the two repositories two not need to be identical. Git Distributive has commands to synchronize the repository or parts of the repository. Git makes it even easier for a team to work together.

Git Local

The basic Git commands:

  • git init – This makes a .git/ directory in the directory that you the terminal is located in. This is your repository. You can browser the files and read them, but you won’t be able to make sense of them unless you are a Git expert. Most OS do not let you see dot-directories. You have to enable that feature.
  • git status – This lets you see all the files in and out of your staging area.
  • git add . – This adds all the files that are not in your staging area to the staging area. You probably want to do this before committing. Don’t use “git add *”.
  • git commit  – This command makes a version in your repository. It will open a text editor for you to write the commit message. Generally the message is one line followed by a blank line and then a detail description of the version or changes.
  • git commit -m “…” – This is a commit with the message on one line. The message should be informative, but only one line.
  • git branch – this lists all your local branches in your repository. You’ll have at least one branch called master. Git makes this branch when you first made the repository using git init. If you have more then one branch then the branch you are on will have a * beside it. This is one way to know what branch you are on, but the prompt in the git bash terminal also indicates the branch that you are on.
  • git branch branchName – This makes a branch with the name branchName. All the files that are currently in the directory structure will be in the branch.
  • git checkout branchName – Moves you to the branch called branchName. It may change the files even remove or add files that are in your directory structure like magic so it matches the version of branchName.
  • git merge branchName – Merges the branch called branchName into the branch that you are on.
  • git branch -d branchName – Deletes the branch called branchName.
  • git log – list current branch commits with number and messages. The reason for good commit messages.
  • git reset 12345678 – Set work space to previous commit, where 12345678 is the commit number, normally copied from the log.

These are the most common commands. They only effect your local repository, but there are more you can do.

In practice, there are a two rules that most people follow.

Local Git Practice Rules:

  • Master is clean. Meaning that anything in master is good code or deplorable and bug free.
  • Branch to develop. Do your experiments in branches and make lots of branches if you need to. You can delete them.

Distributed Git

What sets Git apart from older style CVS is that it has separate commands for controlling your local repository and controlling your remote repository. The remote depository is the repository on GitHub. This means you can experiment all you want on your local machine and keep track of the versions. You only need to push them on to the remote repository when you are ready.

The basic distributed Git commands:

  • git clone https://github.com/HCI-2016/1.git –  This moves all the code from the remote repository into the directory that you are in. It will even make the .git/ directory for you.
  • git branch -r  – This will list the branches in the remote repository, for example origin/master. But in a real project you should have have several branches. The “origin/” designates it as a remote repository branch. You cannot move into, but you can compare versions.
  • git branch -a – This will list both local and remote repositories, for example master and origin/master.
  • git pull – Moves the version on the remote repository into your local branch. You normally only do this on a tracking branch. A  tracking branch is a local branch with the same name as the branch on the remote repository. It should have a corresponding origin/name branch. This is nice to do in order see what other people have pushed up.
  • git fetch origin – This only moves the code into the remote branches on your machine, origin/branchNameFromOrigin. It will update all the branches. If you want to move the code into your local branches then you will have to do a merge.
  • git checkout branchNameFromOrigin – This will make the local branch (if you don’t already have it) and move you into it.
  • git push origin – This will push the files in the current branch up to the remote repository’s branch if you are on a tracking branch.

These are most common commands you will use for distributive version control. If you want to learn more, the best book is on the web:

https://git-scm.com/doc

http://gitref.org/

In practice, there are three rules that most people follow.

Distributive Git Practice Rules:

  • Origin/Master is clean for deployment.
  • Tracking branches are clean or at least believed to be so. 
  • Branch locally to develop. When you are satisfied merge into your tracking branch.

Pull Request

Pull Request is not part of Git. GitHub has added this workflow on it website. The best way to use it is to push to a tracking branch on the remote repository and then ask for a pull request into master or another branch on the repository. See the details at GitHub tutorial:

https://help.github.com/articles/using-pull-requests/

Git Workflow Discussion

  • Should there be a remote feature branches for each team member? How do we merge? How do we test that the code is good?
  • Should there be a remote branch called development  off of master and then feature branches off of development? This way master is always deployable and the feature branches can all be merged into the development branch. After merging the development branch can be deployed. If it is good then it can be merged into master.
  • Should the team merge together? This will help to insure that there are some code review.