blog.negative9.net/contents/articles/git-ready/index.md

title	author	date	template
Git Ready	geoff-doty	2012-10-18	article.jade

Primer on Git source-control management

Overview

Git is a distributed version control system(DVAC) offering a few killer features that sway more developers towards git than any other version control system, for svn these killer features include:

• speed
• local commits
• branching
• merging

SPEED: Everything in git is local, commits, logs, ignores, settings are all stored locally with in a single .git file. This greatly increase the speed at reading logs and reviewing commits.

LOCAL COMMITS: The ability to commit, branch and stash locally allows the developer to commit without affecting other developers or the main codebase until s/he is ready to do so. This also leads to more commits providing a greater identification of the scope of work being done.

BRANCHING: Branches are fast, light-weight as they are only registered as diffs from the branch your diverging. All history is local, and they can be deleted with confidence.

MERGING: Merges are often looked at line-by-line, not file-by-file, so operations tend to be more like: delete_line X, and add_line_X operations. This leads to fewer conflicts. Also if no changes have be made locally, git simply fast-forwards the codebase where merging is not required (FAST!).

Everything mentioned in this document is how git behaves by default. Reading through the document you may ask yourself, "but can I do X?" and the answer is almost always -- "YES, there is option for that!"

1. Setup

setup operations here are one-time set-and-forget

Introduce yourself to git

git config --global user.name "Your Name"
git config -- global user.email "my.email@assist-rx.com"

Line Ending Woes (auto | false)

Different operating system use different line endings. Text editors can negotiate differences seamlessly, as can your version control system -- if you tell it to!

In mixed environments, false maybe the better option, auto, however is a safe default`.

git config --global core.autocrlf false

There are other settings you may be interested in such as

git config --global apply.whitespace nowarn

to ignore whitespace changes.

Handful of Commands

A few git commands your going to be seeing a lot of.

Command	Description
pull	pull commits and merges from a central/shared repo
push	push commits to central/shared repo
commit	commit changes locally
stash	stash code for use later
rebase	set [branch] as the foundation your changes are applied on top of
merge	merge [branch] into the active branch

Remotes

Spring Loops has a ssh key management system, you need to add your public key(if you have one) to the repo you want access to first

git remote add [name] ssh://[user]@[server]/[path]/project.git

Common practice is to name your remote 'origin'

The first time you push/pull changes to a remote (if there is only one), you need to identify where your push/pull should go via

git pull origin master

after that you can just call

git pull

Clone

If a git or svn repo already exists you can clone it which will add a remote automatically for the clone address.

to clone a SVN repo into git use

git svn clone <username>@<server>:/<svn>/<path>/

So you have code, now what?

2. Git Workflow Loop

If you just cloned your repo, you can start coding, however normally you want to pull the latest code before you start coding.

git pull

Again, if you have not previously ran pull, you can pass the [repo] and [branch]. Git will let you know! As an example:

git pull origin master

Develop like only you know how! Netbeans, SublimeText, TextMate -- doesn't matter. Code as you would.

NOTE

I find it best to do all code in a branch. As it always seems to happen if you get pulled into another project mid-step you can do so without affecting the code that you currently written. You can also stash your code. ee Section 3 below for more information._

When your ready to commit your changes, initially you'll find it similar to 'SVN'.

1. Choose the files you want to commit
2. write a commit message and
3. call commit

There are a few command-line options you can pass to make this easier.

git commit -m "[My Commit Message]"

-m stands for message, and this will commit all modified files, however it will not commit new files, to do that you can pass -a, like this:

git commit -am "[My Commit Message]"

Usually you will code . . . commit . . . code . . . commit, as git lends itself better as a source control system than source backup system, however those commits are local, to share your changes you need(for central setup) to push them up to a master or central repository.

BEFORE push, 'pull the latest code!

git pull
git push

Rinse and repeat!

3. Stash, Branch, Tag, and Merge

Stash

Git expects a clean working directory for most operations (pull, push, rebase), but what happens if you have files your working on, and you are not ready to commit those, but you need to pull, merge, or rebase your code?

You stash them!

git stash

Calling the above stashes your changes and brings you to a clean state to call other commands. such as pull.

New files are ignored by git until you add them

When you want your stashed changes back, call

git stash pop

This will apply your stash on top of your current code and delete the saved stash (if successful) ​

Stashes are local only

Tags

Tag specific points in history as being important. Generally, people use this functionality to mark release points (v1.0, and so on) or otherwise known stable points in the history.

git tag [tag_name]

Tag names cannot contain spaces, but you can use ., - or _.

Branches

Git branches are light weight code deviations (stored as diffs), that allow you to quickly jump and build features or try experiments without affecting your main code branch; called master in git or trunk in svn.

Calling git branch by itself will list all the branches that exist with an asterisk(*) next to the branch your currently working in.

To create a new branch you simply call

git branch [name_of_branch]

Then checkout your newly created branch via

git checkout [name_of_branch]

Or you can create a branch and checkout in one line via

git checkout -b [name_of_branch]

REMEMBER: branches are created from the active branch

Now that you've built this awesome feature in a branch, how do you get it back into the main project, lets say master for example?

That's where merging comes in...

Merging

First we need to be on the branch that we want to merge changes into:

git checkout master

then merge in the changes we want with

git merge [name_of_branch]

If there were no conflicts, you can now remove the branch and keep you workspace clean with

git branch -d [name_of_branch]

The branch will be deleted ONLY IF the branch changes have been merged successfully. git is smart enough to only delete changes you have used, but should you want to throw away a branch use the -D option instead of the -d option to force delete the branch.

Squash Merge (advanced)

Sometimes it is advantageous to squash a series of commits in a branch when merging into another branch (such as master) to accurately convey a group of commits belong to a single feature or bug fix.

git checkout master
git merge --squash [name_of_branch]
git commit

Resources

• Git Homepage
• Git Branches