Git

About

Git is a free and open source distributed version control system – which just means that when you do a git clone (+url of your repository) what you are actually getting is a complete copy of your entire history of that project. This means all your commits! Woot!

Git has a staging area. This just means that if you made 100 new changes to your code, you can break these 100 changes into 10 or 20 or more commits each with their own comments and their own detailed explanation of what just happened!

Some claim Git is better than SVN because it works well even for developers who aren’t always connected to the master repository, as it is available offline.

Branching and merging support are thought to be superior with Git, but it is not as efficient at compressing and storing binary files as other versioning systems.

Installation

Configuration

To see a list of git configuration settings, run:

git config --list

Returns something like:

core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true

To see a list of git configuration settings, and where the files they are set in live, run:

git config --list --show-origin

Identity

The first thing to do after installing Git is to set the user name and email address. This is important because every Git commit uses this information, and it’s immutably baked into commits.

  • Set the global git user with:
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

Git can be configured to work with different user accounts per-repository.

  • From within an existing git repository, use the same commands, minus --global to set the user for just that repo:
cd /path/to/my/git/repo
git config user.name "Jane Doe"
git config user.email jane@example.com

Make a New Local Repo

Create a new git repo on a local file system by changing into what will become the new repos root directory and enter:

cd /path/to/my/local/git/repo
git init

After this, add and commit files as normal.

Make a .gitignore File

Create the file .gitignore in the root directory of the repo.
See the (.gitignore example file)[/gitignore-example-file/]

cd /path/to/repo/root
touch .gitignore
git add .gitignore
git commit -m "Added a .gitignore file."

Github

Add a Local Project to Github

  • Create a new repository on GitHub. To avoid errors, do not initialize the new repository with README, license, or gitignore files. These files can be added after the project has been pushed to GitHub.
  • Copy the GitHub remote repository URL from the “Quick setup” section from the repo homepage.
  • In Terminal change to the repository root directory.
  • Add the local repo to the remote repository and make it the origin:
git remote add origin https://github.com/path/to/my/repo.git
  • Verify it by running:
git remote -v
  • Push the local repository content to the remote repo:
git push --set-upstream origin master

MacOS Credentials Management

If you are prompted to enter your username and password before each remote commit, then you are not using stored credentials. Git itself cannot store passwords, but it can use external apps like Keychain to store passwords for it.

Keychain for MacOS

  • Run git config --list to see the git configurations.
  • If this line is present: credential.helper=osxkeychain, then Keychain has already been setup to hold the actual credentials.
  • Open the Keychain app. Go-to the “Login” tab. You should be able to find a github.com entry.
Make Keychain Manage Git Accounts
  • From the git repos root directory run:
git config --global credential.helper osxkeychain
  • On the next action taken in the repo, you will be prompted to enter your credentials again, which will be saved to Keychain.
Reset the Password in Keychain
  • Simply delete the github.com entry from the Keychain app, then re-set the credentials.

On the next action taken in the repo, you will be prompted to enter your credentials again, which will be saved to Keychain.

Use Multiple Github Accounts

Gitflow

See the Gitflow work flow.
http://nvie.com/posts/a-successful-git-branching-model/

Installation

brew install git-flow

Start a New Feature Branch

  • Make sure you checkout the develop branch so your feature is created from the current dev branch.
git checkout develop
  • Pull develop in order to get the most recent version.
git pull

Make the Branch

The GitFlow command to start a new branch is git flow feature start followed by the name of your new feature. Be sure to name your feature something useful (no spaces allowed). For this example we will name our feature Ticket-001_My_New_Feature. The ticket number is to demonstrate that you can use numbers and dashes.

git flow feature start Ticket-001_My_New_Feature

The new feature branch should now be created and you should be on it. To confirm, simply type git status.

You can now freely work, add files, and commit changes to the feature branch like usual.

You can switch back to a feature branch from another branch by typing git checkout feature/ followed by the name of your feature branch.

Terminology

repository

A version-controlled collection of files and directories grouped under a name.

clone

A clone is a copy of a repository. And not just the current iteration, a clone contains the entire repo complete with its entire history.

origin

The origin is the original copy of a repository from which all clones are copied. Developers pull and push to this central copy and use it as the system-of-record for the repository.

branch

A branch is a copy of the repository…inside the repository. The files in a branch are kept separate from all other branches, but all branches are kept in one repository.

master

The master branch is the default branch name given to the repository when creating it with git init.

merge

To combine two branches together in git is called merging. The process is the same as a commit, where files are compared and combined together. Unresolvable combination failures result in a conflict which must be manually resolved before the merge will complete.

conflict

A merge conflict or simply a conflict.

Common Commands

Git Version Number

git version

Check Where Git is installed

which git

Clone a remote origin

Clone a remote repository (origin) located at https://github.com/my-account/example.git into the directory /path/to/local/gitrepo/dir on the local machine:

git clone https://github.com/my-account/example.git /path/to/local/gitrepo/dir

Status of the local repo

From within a repository directory:

git status

git status will display the current branch, its relationship to the origin, any files to be committed and any untracked files.

Create a new branch

Create a new branch in the repo named develop.

git branch develop

Switch branches

Switch from the current branch to the develop branch.

git checkout develop

Create and switch to a new branch

Create a branch and switch to it in one line:

git checkout -b develop

Push a new local branch to the origin

Push the new develop branch to the origin:

git push -u origin develop

Add (stage) untracked files

Add newly created or edited files to the staging area in preparation for a commit.
Add one file at a time:

git add my_file.js

Or add all untracked files:

git add --all

Pull updates from the origin

Make sure you are working with the latest version of the origin by pulling-down any changes from it often, and before committing.

git pull

Commit staged files

Commit all staged files to the local repo:

svn commit -m "A short message about the commit."

Commit message examples:

Fix failing CompositePropertySourceTests
Rework @PropertySource early parsing logic
Add tests for ImportSelector meta-data
Update docbook dependency and generate epub
Polish mockito usage

The following is a valid commit message containing tips for writing good git commit messages:

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary, describing the _what_
and _why_, not the _how_. Wrap lines at about 72 characters or so.  In
some contexts, the first line is treated as the subject of an email
and the rest of the text as the body. The blank line separating the
summary from the body is critical (unless you omit the body entirely).

Further paragraphs come after blank lines.

Write everything in the imperative mood, as if you were commanding
someone. Start the line with "Fix", "Add", "Change" instead of
"Fixed", "Added", "Changed".

  - Bullet points are okay, too.

  - Typically a hyphen or asterisk is used for the bullet, preceded by
    a single space, with blank lines in between, but conventions vary.

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

Push local commits to the origin

git push

Common Processes

Move Current Work to a Feature Branch

Sometime you start down the road on your develop branch, then notice part-way through that this should really be on it’s own feature branch. Stash your current work, create a new branch, then apply the stash to that branch:

git stash
git flow feature start my_new_feature_branch_name
git stash apply

More Resources