Book Giveaway & Exclusive Chapter: Pragmatic Version Control Using Git

DZone and Pragmatic Bookshelf have partnered to bring you this exclusive chapter from 'Pragmatic Version Control Using Git' (by Travis Swicegood). 

Creating Your First Project

Now it’s time to dig into Git. Up to this point, we have talked about abstract ideas and getting set up. That changes in this chapter.

We’re going to work on a small HTML project and use Git to track it. Don’t worry if you don’t know HTML. The markup we’re using here is simple and easy to follow even if you aren’t familiar with HTML.

In this chapter, we’ll do the following:

  • Create a repository
  • Add some files and make some changes
  • Create a new branch
  • Tag a release and clean up our repository release
  • Clone a repository

Once we’re finished, you’ll know the basics you need to get started with Git. This chapter is a high-level overview. There are a lot of new concepts and commands introduced to get you started.

We’ll be covering the commands and concepts introduced here pretty quickly, but each section has references to later parts in the book in case you can’t wait to learn more about something we’re talking about.

I encourage you to follow along with the examples in this chapter and the rest of the book, executing all the commands yourself. We learn via repetition, whether it’s our multiplication tables in grade school or typing a Git command into the command prompt.

3.1 Creating a Repository

Creating a repository in Git is simple, but it seems peculiar if you’re coming from Subversion or CVS. Your repository is something that exists separate from your copy of it in most VCSs. Your repository in Git is stored right alongside your working tree in a directory called .git.

To create a repository in Git, you first need to decide where you want to store your project’s code. In this example, we’re going to create a simple HTML page, so let’s call our project mysite. You need to create
a directory of the same name; then change into it, and type git init. The whole process should look something like this: 

prompt> mkdir mysite
prompt> cd mysite
prompt> git init
Initialized empty Git repository in /work/mysite/.git/

You’re done. You now have a Git repository that is ready to start tracking
your project.

“But there must be more!” you cry. Actually, no. Setting up a Git repository
is an extremely lightweight operation. The git init command sets up
a directory called .git that stores all the repository metadata, and the
empty directory we’re in, mysite, serves as the working tree of code you
have checked out from the repository.

Click here to download the entire excerpt.

 

The above excerpt was extracted from Pragmatic Version Control Using Git, published in December 2008 by Pragmatic Bookshelf. It is being reproduced here by permission from Pragmatic Bookshelf. For more information or to purchase a paperback or PDF copy, visit the Pragmatic Version Control Using Git homepage.

Copyright © 2008 Travis Swicegood. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher.

AttachmentSize
DZoneTSGIT.pdf161.86 KB
bookcontest_git.png47.5 KB
0
Average: 5 (1 vote)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Stephen Robillard replied on Thu, 2009/08/27 - 9:53pm

I look forward to reading this for two reasons. First I have clients who are using it rather than subversion (at least for third party developers), and two the pragmatic's subversion book is one of the few that was not just a rehash of the documentation.

Sudhakar Ramasamy replied on Thu, 2009/09/24 - 9:50pm

Being a long time subversion user, I had comfort in being tied to my source code living on a server that was backed up regularly. So when I first heard about DVCS and git, the very idea of having multiple copies of my source code all over the place and no single source of truth sounded like a crazy idea. But as I've slowly explored git over the last few months, I can't wait to let go of the server (svn) and hit the open road. Git has been just a pleasure to work with. Granted I am yet to use Git for anything besides my hobby projects the documentation I've seen so far says you can set it up to completely replace an svn server and still keep a single source of truth that your CI server builds from. This book seems like it would be a handy guide as most all book in the pragmatic series are. Would love to have a copy!

Josh Marotti replied on Mon, 2009/11/16 - 5:02pm

Git is just a whole new way of thinking of version control.  Moving from a 'centralized server' to a 'cloud server which you are an independent node' with version control can take quite a while to wrap your head around, but once you do you realize all the doors this opens. 

No network connections needed to get work done and still have full history?  Great!

Oh you wanted a centralized server process?  Still completely possible and used as such to transition!


Just a great new way of handling source control!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.