Pro Git

Pro Git

Scott Chacon, Ben Straub

Language: English

Pages: 456

ISBN: 1484200772

Format: PDF / Kindle (mobi) / ePub

Pro Git (Second Edition) is your fully-updated guide to Git and its usage in the modern world. Git has come a long way since it was first developed by Linus Torvalds for Linux kernel development. It has taken the open source world by storm since its inception in 2005, and this book teaches you how to use it like a pro.

Effective and well-implemented version control is a necessity for successful web projects, whether large or small. With this book you’ll learn how to master the world of distributed version workflow, use the distributed features of Git to the full, and extend Git to meet your every need.

Written by Git pros Scott Chacon and Ben Straub, Pro Git (Second Edition) builds on the hugely successful first edition, and is now fully updated for Git version 2.0, as well as including an indispensable chapter on GitHub. It’s the best book for all your Git needs.

What you’ll learn

• Effectively use Git, either as a programmer or a project leader

• Become a fluent Git user

• Master branching, using Git on the server, and on other systems

• Integrate Git in your development workflow

• Migrate programming projects from other SCMs to Git

• Extend Git for your personal project needs

• Effectively use GitHub

Who this book is for

This book is for all open source developers: you are bound to encounter Git somewhere in the course of your working life. Proprietary software developers will appreciate Git’s enormous scalability, since it is used for the Linux project, which comprises thousands of developers and testers.

Table of Contents

1. Getting Started

2. Git Basics

3. Git Branching

4. Git on the Server

5. Distributed Git

6. GitHub

7. Git Tools

8. Customizing Git

9. Git and Other Systems

10. Git Internals

The Little Schemer (4th Edition)

Introducing Maven

Python Machine Learning

Principles of Data Mining (2nd Edition) (Undergraduate Topics in Computer Science)

GPU Pro 7: Advanced Rendering Techniques












Sequence of this managed-team workflow. Public Small Project Contributing to public projects is a bit different. Because you don’t have the permissions to directly update branches on the project, you have to get the work to the maintainers some other way. This first example describes contributing via forking on Git hosts that support easy forking. The and GitHub hosting sites both support this, and many project maintainers expect this style of contribution. The next section.

will let you give the end user more specific instructions about tag verification. Generating a Build Number Because Git doesn’t have monotonically increasing numbers like ‘v123’ or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run git describe on that commit. Git gives you the name of the nearest tag with the number of commits on top of that tag and a partial SHA-1 value of the commit you’re describing: $ git describe."\n").reject { |line| line == '' } access = {} acl_file.each do |line| avail, users, path = line.split('|') next unless avail == 'avail' users.split(',').each do |user| access[user] ||= [] access[user] << path end end access end On the ACL file you looked at earlier, this get_acl_access_data method returns a data structure that looks like this: {"defunkt"=>[nil], "tpw"=>[nil], "nickh"=>[nil], "pjhyett"=>[nil], "schacon"=>["lib", "tests"],.

Figure 9-3. All the objects in your Git directory. Object Storage I mentioned earlier that a header is stored with the content. Let’s take a minute to look at how Git stores its objects. You’ll see how to store a blob object — in this case, the string “what is up, doc?” — interactively in the Ruby scripting language. You can start up interactive Ruby mode with the irb command: $ irb >> content = "what is up, doc?" => "what is up, doc?" Git constructs a header that starts with the.

Adding a branch that points to that SHA. Removing Objects There are a lot of great things about Git, but one feature that can cause issues is the fact that a git clone downloads the entire history of the project, including every version of every file. This is fine if the whole thing is source code, because Git is highly optimized to compress that data efficiently. However, if someone at any point in the history of your project added a single huge file, every clone for all time will be.

Download sample