Version: 0.0.1
-
Tim Harvey - Literacy5 | twitter.com/tihm
-
Michael Krisher - krash inc | twitter.com/mkrisher
Git is a free and open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency. (git-scm.com/)
Git is used for version control of files, much like tools such as Mercurial, Bazaar, Subversion, CVS, Perforce, and Visual SourceSafe.
Version control is the management of changes to documents, programs, and other information stored as computer files. Version control is often referred to as SCM (source control management). It is most commonly used where a team of people may be changing the same files. Changes are usually identified by a number or letter code, termed the “revision number”, “revision level”, or simply “revision”. For example, an initial set of files is “revision 1”. When the first change is made, the resulting set is “revision 2”, and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged. (en.wikipedia.org/wiki/Revision_control)
A big part of the argument for using a form of version control ultimately stems back to software craftsmanship. As professionals, we strive to build reliable, maintainable code for ourselves and others. Version Control holds an important place in the toolkit.
Version control augments your memory and gives you a safety net when things go wrong. At its very basic level, it helps you recall what you changed, even months later, and acts as an extremely robust backup. More sophisticated version control systems speed development by allowing multiple devs to work in the same code files at one time and allow management of multiple versions and features.
-
Detailed log of every change
-
Roll back changes quickly
-
Teamwork without stepping on toes
-
Deployment automation
-
Maintain separate production release code and development code
-
Quickly make duplicate sets of files to test changes
-
Free and open source
-
Easy to setup locally and on a remote server (Windows OS as an exception)
-
No remote server needed, Git was designed from the ground up as a distributed version control system
-
All Git benefits are in place locally versus on the server
-
Git is fast, performance is much better than others
-
Git repo file sizes are smaller than others like Subversion
-
no access control, because the repos are distributed and not controlled through the central repo on the server
-
no GUIs really, gitx doesn’t really count compared to TortoiseSVN, or SVNx
-
partial checkout is not supported in Git, you do a pull or checkout and get the entire repo
-
Git uses large SHAs for revision numbers, where SVN increments starting at 1
Just because you are not co-writing files doesn’t mean you can’t benefit from Git
-
Branching is a really powerful way of creating a replicant of your master files so you can try something new and not have to back out a lot of changes
-
using a remote server means an offsite backup that can quickly be restored if needed
In short, if you work in a team environment without a version control system, you are out of your mind.
-
Git is a free distributed revision control, or software source code management project with an emphasis on being fast. Git was initially designed and developed by Linus Torvalds for Linux kernel development.
-
Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.
-
Branching is fast and easy. New features may be built up in separate branches and easily merged in when complete.
-
GitHub. A “social coding” tool, GitHub offers sharing and collaboration. You can publish public repos, work on private repos, and keep up to date on changes to tools you use. Find an issue with someone else’s code? No probelem! There is a mechanism to grab a copy of their project, make the fixes, then they can automatically merge your changes in.
-
A repository is just a set of files that are under version control. For example anything in a folder or directory.
-
A repository is “watched” by version control applications for any changes to files, documents, or programs
From the command line issue the following:
-
mkdir test
-
cd test
-
git init
That’s it. The “test” directory is now under Git’s watchful eye.
You add files and track changes. So let’s add a file.
-
touch README
-
git status
-
git add README
-
git status
-
git commit -m “init add of the README”
-
git status
Now we continue to add the files that we need and as we make changes we commit those changes. To see what that looks like edit the README, then issue a git status
What if we want to add a file to the directory but don’t want Git to track it? Git has built in ignoring!
-
create a new file called .gitignore
-
add the file name (or directory name) of the file you want to ignore
-
note: this should be done before you ever add the file using “git add”
-
branching allows you to create a duplicate set of files locally, without physically creating a whole duplicate set of files. huh?
-
branching allows a developer to maintain a working copy of the site, called the master branch, and also have multiple other copies of the site for adding new features, writing tests, etc…
-
merges are recorded as part of the proper history of the repository
As an example, I have my working branch called master. The master branch is the set of files that are currently live on the server. But the client has called and has asked me to add a contact form. I can quickly create a “contact” branch. The contact branch IS the master branch files, but I can make changes to the files and if I switch back to the master, those changes will not be represented.
Demo time: Let’s say I create a new file contact.html in the contact branch. If I switch back to the master branch, the contact.html file will not be there. Not until I merge the branches or copy over the file. Notice I did not copy a bunch of files and paste them when creating the contact branch. Git just keeps track of the files present and lines in the files I have changed as I move from branch to branch.
So why is this powerful. Now let’s say that the client calls and there is a typo on one of the pages. I don’t want to include my contact branch changes, I just want to fix the typo and deploy that quick change. Luckily, all I have to do is switch back to the master branch, make the change and then deploy. This example isn’t very complex, but let’s say you were right in the middle of completely changing the top navigation of a site. You don’t want to back everything out, just to fix a small error.
So now let’s say I am finished with the contact form. It is ready to go and be deployed. I can go back to my master and pull in all the changes I have made to the contact branch. git merge contact. Then I can remove the contact branch since it is not needed any longer.
Now each iteration of the site gets a new branch, the new files and lines are added, then once finished they are merged back into the master. This workflow syncs up beautifully with Test Driven Development where each thing you add to a site is spelled out.
Previously we mentioned fixing a typo in the master branch. Nothing huge. But let’s say the change was more significant, or a team member has made a large merge into the master branch and we have pulled that in. We want to make sure that what we are doing in our contact branch does not cause a conflict. We need to get those master changes into our contact branch. This is called rebasing.
Rebasing is simply done by issuing git rebase master, while in the contact branch. However, there can be conflicts. Let’s say your team member has made an update to the README, and you have done the same. While doing the rebase, Git will tell you what files are not in sync.
You have to open those files, and fix the conflicts designated by git with symbols like <<<<<<<<<<<<<HEAD, etc.…
Once you have fixed the conflicts, you should add those changes to your contact branch, using git add. As always, the files will all show with a git status.
Git provides a dead simple way of quickly viewing the commit history of the repo by doing a git log and seeing each commit, it’s message, SHA, and author
Git logging makes it extremely easy to see when a change was introduced, the message attached and who committed it. Makes it easy to see when something was introduced whether that is a bug, feature, etc.… Pretty self explanatory
You can also use the Log to see previous commits if you want to ever rollback to or checkout a previous state of the repo. git log –stat will include the files that were changed in each commit.
As with any version control system, a major benefit is seeing the difference of file version to file version. Git makes viewing diffs very easy.
The first way is through the built in server that comes with git. Just issue the gitweb command. Once running the complete log of the current repo is available at 127.0.0.1:1234
The web interface makes it very very easy to view the diffs in a file.
This party tools such as GitX and GitK make it easy to view diffs, branches, and merges.
But let’s say you have a file marked as ready to commit, but you don’t remember what you changed. Before you commit the file simply issue a git diff command
But you know you commited a file last time and you can’t remember what you changed, simply step back through the revision of the branch doing a git diff master~1 or to step back three commits ago git diff master~3
This is just touching the surface of Git. Hopefully you are interested in trying it out. Thanks, and tip your waiters!