7.8 KiB
| title | author | date | template |
|---|---|---|---|
| Git Ready | geoff-doty | 2012-10-18 | article.jade |
What is Git? How does it help developers? Why is it killing every other source control management system out there? When can I use it?
Learn more with this 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 alsostashyour code. ee Section 3 below for more information._
When your ready to commit your changes, initially you'll find it similar to 'SVN'.
- Choose the files you want to commit
- write a
commitmessage and - 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, 'pullthe 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
addthem
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