使用 Git 实现实用版本控制

5星 · 超过95%的资源需积分: 10 128 浏览量更新于2024-08-02 1 收藏 3.51MB PDF 举报

版本控制使用 Git 的实践指南版本控制是软件开发过程中的一项重要实践，旨在跟踪和管理代码库的变化。 Git 是一种流行的版本控制系统，广泛应用于软件开发领域。《Pragmatic Version Control using Git》是一本实践指南，旨在指导读者如何使用 Git 实现版本控制。 Git 的优点相比其他版本控制系统，Git 具有许多优点： 1. 分布式版本控制：Git 是一种分布式版本控制系统，每个开发者都可以在本地拥有整个版本库的副本，从而提高了开发效率和灵活性。 2. 高度灵活：Git 允许开发者在不同的分支上工作，方便多人合作和代码审核。 3. 快速提交：Git 的提交速度非常快，能够快速地提交代码变化。 4. 安全：Git 使用 SHA-1 哈希算法来确保代码的安全和一致性。 Git 的基本概念 1. 仓库（Repository）：存储所有版本信息的数据库。 2. 提交（Commit）：将代码变化提交到仓库中。 3. 分支（Branch）：用于并行开发和管理代码的分支。 4. 合并（Merge）：将不同的分支合并到一起。使用 Git 的好处 1. 版本控制：Git 能够跟踪代码的变化，方便代码回溯和 version 管理。 2. 多人合作：Git 允许多人同时在不同分支上工作，提高开发效率。 3. 快速提交：Git 的快速提交功能能够快速地提交代码变化。 4. 安全：Git 的安全机制能够确保代码的安全和一致性。使用 Git 的步骤 1. 安装 Git：下载并安装 Git 客户端。 2. 创建仓库：使用 Git init 命令创建一个新的仓库。 3. 添加文件：使用 Git add 命令添加文件到仓库中。 4. 提交变化：使用 Git commit 命令提交代码变化。 5. 创建分支：使用 Git branch 命令创建一个新的分支。 6. 合并分支：使用 Git merge 命令将不同的分支合并到一起。 Git 的应用场景 1. 软件开发：Git 广泛应用于软件开发领域，用于版本控制和多人合作。 2. 文档管理：Git 可以用于管理文档的版本，跟踪文档的变化。 3. 科研合作：Git 可以用于科研合作，跟踪研究数据和结果的变化。 Git 是一种功能强大且灵活的版本控制系统，能够帮助开发者更好地管理代码和合作。《Pragmatic Version Control using Git》是一本实践指南，旨在指导读者如何使用 Git 实现版本控制。

THE REPOSITORY 16

1.1 The Reposi t ory

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

of all the changes you make. Most store the current state of the code,

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

message that explains wh y they made the change.

You can think of a repository like a bank vault and its hist ory like the

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

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

for safekeeping.

Originally, these repositories were accessible only if you w ere 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 th e repository and send their changes

back using a n etwork connection.

These systems follow a centralized repository model. That means there

is one central repository that everyone sends their changes to. E ach

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 r epository is an improvement over having to directly

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

tions. First, you h ave only the latest version of the code. To look at the

history of changes, you have t o ask the repository for that i nformation.

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, we forget that

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

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

country plane ﬂights, and on the road (as a passenger) while 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, y ou each have

your own repository that has the entire history of the pr oject. Making

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

is recorded in your local repository.

Report erratum

this copy is (P1.0 printing, November 2008)

Prepared exclusively for Matt Hargett

WHAT SHOULD YOU STORE? 17

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

system is like 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 every one 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 to t he main repository (an action called

pushing in Git), or they mig ht have to submit patches, which are small

sets of changes, to the pr oject’s maintain er and have th em update the

main repository.

1.2 What Shou l d You Store?

The short answer: everything.

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

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

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

The ﬁrst and most obvious thing you should store in the 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 i tems to st ore in your repository are sample conﬁgura-

tion ﬁles, documentation, images that are used in th e 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, t here 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 progr am 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 (P1.0 printing, November 2008)

Prepared exclusively for Matt Hargett

WORKING TREES 18

1.3 Working Trees

So far w e’ve discussed the repository and t alked 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 is your current view into t he repository. It has all the

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

Some VCSs refer to this as your working copy. People coming t o 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/ dir ect ory inside 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 t hen tell Git to initialize a repository for it;

or you can clone an existing repository.

Cloning makes a copy of anoth er 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,

Cloning a Remote Repository, on page 103.

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

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

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

cover that.

1.4 Manipulatin g Files and Stay i ng in Sync

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

a VCS. You make changes t o 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 t o t he 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 int roduced.

Report erratum

this copy is (P1.0 printing, November 2008)

Prepared exclusively for Matt Hargett

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 w hen 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 sync. You

also have to fetch changes to get the latest 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 to 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 w ay 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 an d

from multiple repositories. Working with remote repositories is a core

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

ter

7, Working with Remote Repositories, on page 100.

1.5 Tracking Projects, Directories, and File s

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

we’ll talk about how t o organ i ze the things you store.

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

content. This is different fr om many version control systems t hat track

ﬁles. Instead of tracking 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 (P1.0 printing, November 2008)

Prepared exclusively for Matt Hargett

TRACKING MILESTONES WITH TAGS 20

Technically, this has a lot of advantages. It reduces the amount of stor-

age space needed to store th e entire history 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, Following Con-

tent, on page

88.

You 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 t he ﬁles and dir ectories 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 h owever you like. You can

create a new directory in the repository for each project so t he projects

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

project.

Coming up with t he perfect balance is challeng i ng for someone new to

the VCS worl d. In Chapter

8, Organizing Yo ur 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 Mileston es w i t h Tags

As projects progress, they hit milestones. Maybe you follow an agile

methodology and have weekly development cycles where 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 (P1.0 printing, November 2008)

Prepared exclusively for Matt Hargett

剩余183页未读，继续阅读

yangjingxu

粉丝: 1

使用 Git 实现实用版本控制

Pragmatic Version Control Using Git

Pragmatic_Version_Control_-_Using_Git

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

pragmatic指令

the pragmatic programmer pdf

the pragmatic programmerpdf

在软件开发中，如何平衡代码的灵活性、重用性与维护性？请结合《Pragmatic Programmer》中提到的原则与案例进行解答。

the pragmatic programmer

tms320c54xx支持pragmatic指令吗

Django first

最新资源