《Pragmatic Version Control with Git》：新手指南与协作技巧

需积分: 10 120 浏览量更新于2024-07-23 收藏 3.86MB PDF 举报

《Pragmatic Version Control with Git》是一本深受读者推崇的实用指南，专为初学者和经验丰富的开发者设计，帮助他们深入了解并掌握Git这一强大的版本控制系统。作者Travis 的文字深入浅出，不仅教会读者如何快速上手Git，还涵盖了团队协作和维护代码历史的最佳实践。该书的核心内容包括： 1. **Git基础知识**：对于那些初次接触Git的人来说，书中会提供详细的入门教程，让读者了解Git的基本概念、工作流程和命令行操作。这包括版本追踪、分支管理、合并代码变更以及提交历史记录的维护。 2. **分布式版本控制**：《Pragmatic Version Control with Git》着重强调了Git的分布式特性，区别于传统的集中式版本控制系统，如CVS。这使得用户在本地可以拥有完整的项目副本，提高了效率，并减少了网络依赖。 3. **团队协作与冲突解决**：书中指导读者如何有效地与其他开发者协同工作，包括拉取请求、代码审查、分支策略等，以及如何在出现冲突时妥善处理。 4. **适应现有环境**：即使在没有完全切换到Git的环境中，该书也展示了Git的价值。读者可以在继续使用CVS或Subversion的同时，学会利用Git的优点，提升个人和团队的工作效率。 5. **实战应用与实例**：书中提供了丰富的实际场景和案例，帮助读者通过实践加深理解和技能的掌握，确保理论与实践相结合。 6. **专业认可**：来自Pieter de Bie（GitX作者）、Jacob Taylor（SugarCRM Inc. 创业者及联合创始人）和Chuck Burgess（2008年PEAR Group成员）的积极评价证实了这本书作为Git学习资料的价值，他们鼓励读者无论是否已经在使用其他版本控制系统，都应阅读这本书并掌握Git。《Pragmatic Version Control with Git》是一本既适合初学者系统学习，也适合有一定经验的开发者提升Git技能，实现更高效、更灵活的代码管理和协作的实用指南。通过阅读这本书，读者不仅能掌握Git的基本操作，还能领悟到其带来的革命性变化，为项目管理和团队协作带来实质性的改变。

THE REPOSITORY 16

1.1 The Repository

The repository is the place where the version control system keeps track

of all the changes you make. Most VCSs store the current state of the

code, along with when each change was made, who made it, and a text

log message that explains why th ey made the change.

You can think of a repository like a bank vault and its hi story like the

ledger. Each time a deposit—what is called a commit in VCS lingo—is

made, your VCS tool adds an entry to the ledger and stores the changes

for safekeeping.

Originally, these repositories w ere accessible only if you were logged

directly into the machines they were stored on. That doesn’t scale, so

tools such as CVS, and later Subversion, were created. They allowed

developers to work remotely from the repository and send their changes

back using a network connection.

These systems follow a centralized repository model. That means there

is one central repository that everyone sends their changes to. Each

developer keeps a copy of the latest version of the repository, and when-

ever they make a change to it, they send that change back to the main

repository.

The centralized repository is an improvement over having to directly

access the machine where the repository lives, but it still has limita-

tions. First, you have only the latest version of the code. To look at th e

history of changes, y ou h ave to ask the repository for that information.

That brings up the second problem. You have to be able to access the

remote repository—normally over a network.

In this age of always-on, broadband Internet connections, w e forget that

sometimes we don’t have access to a network. As I’ve worked on this

book, I’ve written parts at my home ofﬁce, in coffee shops, on cross-

country plane ﬂights, and on the road (as a passenger) wh i l e traveling

across country. I even did some of the ﬁnal editing at a rustic cabin in

Lake of the Ozarks, Missouri.

That highlights one of the biggest advantages of a DVCS, which is the

model that Git follows. Instead of having one central repository that

you and everyone else on your team sends changes to, you each have

your own repository that has the entire history of t he project. Making

a commit doesn’t involve connecting to a remote repository; the change

is recorded in your local repository.

Report erratum

this copy is (P2.0 printing, March 2009)

Prepared exclusively for Trieu Nguyen

Download at Boykma.Com

WHAT SHOULD YOU STORE? 17

Let’s go back to our bank vault analogy for a minute. A centralized

system is li ke having one bank that every developer on your team uses.

A distributed system is like each developer having their own personal

bank.

You might be wondering how you can keep in sync with everyone else’s

changes and make sure they have yours. Each developer still sends

their changes back to the main project repository. They can have access

to send the changes directly t o the main repository (an action called

pushing i n Git), or they might have to submit patches, which are small

sets of changes, to the project’s maintainer and h ave them update the

main repository.

1.2 What Should You Store?

The short answer: everything.

The slightly less short answer: everything that you need to work on

your project. Your repository needs a copy of everything in your project

that’s essential for you t o modify, enhance, and build new versions of it.

The ﬁrst and most obvious thing you should store in th e repository is

your project’s source code. Without that , you can’t ﬁx bugs or imple-

ment new features.

Most projects have some sort of build ﬁles. A couple of common ones

are Makeﬁles, Rakeﬁles, or Ant’s build.xml. These need to be stored so

you can compile your source code into something usable.

Other common items to store in your repository are sample conﬁgura-

tion ﬁles, documentation, images that are used in the application, and

of course unit tests.

Determining what to include is easy. Ask yourself, “If I didn’t have X,

could I do my work on this project?” If the answer is no, you couldn’t,

then it should be included.

Like all good rules, there is an exception. The rule doesn’t apply to tools

that you should use. You should include the Ant build.xml ﬁle but not

the entire Ant program.

It’s not a hard exception, though. Sometimes storing a copy of Ant or

JUnit or some other program in your repository can make sure the

entire team is using the same version of the tools you use. These should

be stored separately from your project, however.

Report erratum

this copy is (P2.0 printing, March 2009)

Prepared exclusively for Trieu Nguyen

Download at Boykma.Com

WORKING TREES 18

1.3 Working Tr ees

So far we’ve discussed th e repository and talked about all the ﬁles

you’re storing in it, but we haven’t talked about where you make all

of your changes. This happens in your working tree.

The working tree i s your current view into the repository. It has all the

ﬁles f rom your project: the source code, build ﬁles, unit tests, and so on.

Some VCSs refer to thi s as your working copy. People coming to Git

for the ﬁrst time from another VCS often have trouble separating the

working tree from the repository. In a VCS such as Subversion, your

repository exists “over there” on another server.

In Git, “over there” means in the .git/ directory in side your project’s

directory on your local computer. This means you can look at the his-

tory of the repository and see what has changed without having to com-

municate with a repository on another server.

So, how do you get this working tree in the ﬁrst place? Well, you can

start your own project and then tell Git to initialize a repository for it;

or you can clone an existing repository.

Cloning makes a copy of another repository and then checks out a copy

of its master branch—its main line of development. Checking out is the

process Git uses to change your working tree to match a certain point in

the repository. We’ll talk more about cloning repositories in Section 7.2,

loning a Remote Repository, on page 103.

Of course, a VCS is all about tracking changes. So far, we’ve talked

about repositories and y our working tree—your current view of the

repository—but we haven’t talked about those changes yet. Now we’ll

cover that.

1.4 Manipulating Files and Staying in Sync

Tracking changes to your ﬁles over time is the whole reason for using

a VCS. You make chang es to the source code, rerun your unit tests to

make sure your changes don’t have any side effects, and then commit

those changes.

Committing a change adds a new revision to the repository and stores

your log message explaining what the change did. This gives you a

recor d to go back through if you ever need to ﬁgure out why a certain

change was made or when a bug was introduced.

Report erratum

this copy is (P2.0 printing, March 2009)

Prepared exclusively for Trieu Nguyen

Download at Boykma.Com

TRACKING PROJECTS, DIRECTORIES, AND FILES 19

A DVCS such as Git requires that you share your changes with other

developers in order for them to have access to them. This is done by

pushing the changes to an upstream repository.

An upstream repository is a public repository that you and possibly

other developers all push changes to. Pushing is what you do when you

want to send your data to another repository so it can be shared with

other developers.

Pushing changes is just half of what you need to do to stay in syn c. You

also have to fetch changes to get the lat est updates from other members

on your team.

There are two steps to retrieving changes from a remote Git repository.

First, you fetch them. That creates a copy of the remote repository’s

changes for you. This step is sort of like the reverse of pushing. Instead

of sending changes t o another repository, you ask the remote repository

to send you the changes it has.

Next, you merge those changes into your local history. Git provides

tools that help you merge changes. Since you normally want to fetch

and merge changes at the same time, Git provides a way to do both

in one step through a process called pulling. Pulling is similar to an

update command in Subversion or CVS.

Git is fully distributed, though. You can push and pull changes to and

from multiple repositories. Working w i th r emote repositories is a core

part of fully understanding how Git works. We’ll cover it fully in Chap-

ter

7, W

orking with Remote Repositories, on page 100.

1.5 Tracking P rojects, D i r ectories, and F i l es

So far you’ve seen how to store your code in r epositories. In this section,

we’ll talk about how to organize the things you store.

At the lowest level, Git tracks the ﬁles you store in your repository as

content. This is diff erent from many version contr ol systems that track

ﬁles. Instead of t racking a models.py ﬁle, Git tracks the content—the

individual characters and lines that make up the variables, functions,

and so on—of models.py, and Git adds metadata to it such as the name,

ﬁle mode, and whether the ﬁle is a symlink. It’s a nuanced difference,

but it’s an important one.

Report erratum

this copy is (P2.0 printing, March 2009)

Prepared exclusively for Trieu Nguyen

Download at Boykma.Com

TRACKING MILESTONES WITH TAGS 20

Technically, this has a l ot of advantages. It reduces the amount of st or-

age space needed to store the ent i re hist ory of your repository and

makes it feasible and fast to do things, such as detecting functions

or classes moving between two ﬁles or determining where copied code

came from. We’ll cover this in more detail in Section 6.5, F

ollowing Con-

tent, on page

88.

ou interact with the data in those ﬁles exactly like you do any other

ﬁles. All your work happens in the working tree. It’s a set of normal

directories and ﬁles that represents your current view of the repository.

The way you organize th e ﬁles and directories in your repository makes

up your project. Most projects follow a speciﬁc structure so everyone

on the team knows where to put ﬁles so everyone else can ﬁnd them.

Most companies, however, have more than one project. Some larger

projects might even be broken down into several modules to make them

more manageable. How you structure these modules within repositories

is up to you.

Git allows you to structure your repositories however you like. You can

create a new directory in the repository f or each project so the pr ojects

share a common history, or you can create a new repository for each

project.

Coming up with the perfect balance is challenging for someone new to

the VCS world. In Chapter 8, O

rganizing Your Repository, on page 109,

we’ll cover some of the ways you can structure your repository.

We’ve covered the basics now. You know what a repository and your

working tree are. You know that your project is just how you lay out

the contents of your repository. Now let’s explore tags.

1.6 Tracking Milestones with Tags

As projects progress, they hit milestones. Maybe you follow an agi l e

methodology and have weekly development cycles wher e some new fea-

ture is added every week, or maybe you’re on a traditional cycle where

updates are released every few months.

Either way, you need to keep track of what state your repository was in

when you passed that milestone. Tags give us the tool to do that. They

mark a certain point in the history of the repository so you can easily

reference them later.

Report erratum

this copy is (P2.0 printing, March 2009)

Prepared exclusively for Trieu Nguyen

Download at Boykma.Com

剩余183页未读，继续阅读

sinat_20683553

粉丝: 0
资源: 3

《Pragmatic Version Control with Git》：新手指南与协作技巧

Pragmatic Version Control实效版本控制

Pragmatic Version Control With Subversion

Pragmatic Version Control using Git

Git入门指南：Pragmatic Version Control Using Git

Git大全 Git官网上列出的五本书

CoffeeScript - Accelerated JavaScript Development

使用 Git 实现实用版本控制

使用Git的实用版本控制

掌握Git：实用版本控制指南

Git入门指南：英文原版详细解读

最新资源