Git for Humans: Mastering Version Control for Web Creators

需积分: 0 69 浏览量更新于2024-06-28 收藏 1.5MB PDF 举报

"《2016-A Book Apart Git for Humans》是一本面向网页制作人员的简明书籍，由David Demaree撰写，由A Book Apart出版。这本书旨在帮助理解和掌握Git这一版本控制系统，以便更好地进行网站开发和协作。书中还提到了其他A Book Apart出版的相关设计与开发主题的书籍，如响应式设计、触屏设计、负责任的响应式设计等内容。" 本文主要涉及的知识点是Git，这是一种分布式版本控制系统，对于软件开发，尤其是协作开发来说至关重要。Git允许开发者跟踪代码变更，管理项目的不同版本，并方便地在团队成员间协同工作。以下是关于Git的一些关键概念和操作的详细解释： 1. **版本控制**：Git的核心功能是版本控制，它记录了文件和目录的每次修改，使开发者可以回滚到任何历史版本，避免因错误修改导致的问题。 2. **仓库（Repository）**：在Git中，仓库是存储项目文件和元数据的地方，包含了项目的完整历史。开发者可以本地创建仓库，也可以在远程服务器上（如GitHub或GitLab）建立仓库。 3. **克隆（Clone）**：克隆一个仓库意味着复制整个仓库的结构和历史到本地，这样就可以在本地进行开发工作并推送到远程仓库。 4. **分支（Branches）**：Git的分支机制允许开发者在不同的开发路径上工作。主分支通常命名为`master`，新功能或修复通常在新的分支上开发，完成后合并回主分支。 5. **提交（Commit）**：提交是保存对文件的更改，每次提交都会记录作者、日期和提交信息，形成版本历史的一部分。 6. **合并（Merge）**：当两个或多个分支有共同的祖先并且各自发展时，合并就是将这些分支的更改整合在一起的过程。 7. **远程（Remotes）**：远程是指在另一台机器上的Git仓库。通过远程仓库，团队成员可以共享代码，协作开发。常见的远程操作包括`fetch`（获取远程仓库的更新）和`push`（推送本地更改到远程仓库）。 8. **Pull请求（Pull Request）**：在Git服务如GitHub上，当开发者想要将他们的分支合并入主分支时，会发起一个Pull请求，等待其他团队成员审查和合并。 9. **冲突（Conflicts）**：当两个或多个分支修改了同一部分代码时，合并可能会产生冲突。解决冲突需要手动检查并选择保留哪部分代码。 10. **工作流（Workflow）**：有效的Git工作流如GitFlow或GitHub Flow，定义了如何创建、合并分支以及处理生产环境的更新，有助于团队的高效协作。《Git for Humans》这本书可能涵盖了这些概念的介绍和实践指导，以帮助非技术背景或者初学者理解并熟练使用Git。同时，书籍的作者David Demaree可能通过简单易懂的方式解释复杂的Git概念，使得读者能够快速上手并应用于实际的网站开发工作中。

11THINKING IN VERSIONS

Imagine you and I are collaborating on a website. You’re

exploring what it would look like if we changed all the links on

the site from blue to green, while I am considering changing

the link color to red. Under the rules of our version control

system, I should make and save my changes to the copy of the

stylesheet le in the directory. Unfortunately, the rules also say

you should make your change in the exact same place. Following

this method, whether the links are going to be green or red in

the next numbered version of the project depends entirely on

which of us made our change last. If I saved my le later than

you saved your le, my changes win.

The only way to avoid this clobbering is for individuals inter-

ested in submitting changes around the same time—you and

me, in this case—to work together to make sure that either our

changes don’t conict or that our version control system some-

how automatically reconciles or rejects conicting changes.

Some primitive version control systems solve this problem

by requiring people to “check out” a le, like a book from the

library. Checking a le out marks it as uneditable by anyone else

until the person who checked it out has both nished editing

and explicitly checked it back in. This addresses the risk of

unintended le-clobbering (by making accidental overwrites

impossible), but it also creates a new problem: if I’m the one

with the homepage le checked out, you’re stuck waiting on

me to nish before you can do your work.

DISTRIBUTED COLLABORATION

Instead of having one working copy shared by everyone, we

can require all team members to have their own working copies

stored on their own computers. In theory, at least, that allows

each of us to work independently until it’s time to save a new

ocial version.

There’s still a small risk of two people trying to commit

versions at the same time, but that happens less frequently

than just saving changes while working, and we can coordinate

those kinds of changes easily—“Hey, I’m going to push version

13THINKING IN VERSIONS

how can we know what color the links should be in the next

ocial version?

More importantly, how can we know what else might have

changed? What if, in addition to the changed link color, your

copy of the website includes a lovely new page explaining the

company’s mission that isn’t in my copy, and mine has a x for

an annoying JavaScript bug that isn’t in your copy?

This is where our homegrown version control system com-

pletely breaks down. It’s not that we can’t work together to

combine our two working copies into a single version; it’s that

doing so takes up valuable time we’d much rather spend writ-

ing, designing, coding, making coee, or browsing Tumblr for

cat GIFs. Auditing our work les for conicting changes is no

fun; more importantly, it doesn’t scale. As we add more les,

more collaborators, and more changes, the risk of accidentally

introducing major problems increases.

Remember that version control is more than just the ver-

sions: it’s the rules and processes for managing versions. Once

you have a lot of les, a lot of collaborators, or both, it can be

exhausting to enforce those rules without a referee—and only

by enforcing the rules consistently can you trust your version

control system enough to get any value out of it.

Fortunately, all of these things—enforcing rules, keeping

track of versions in a repository of past work, shuttling changes

back and forth between the repository and your working copy,

even merging together two directories and policing conicts—

are things that computers can do a lot faster and better than

we can. By learning and adopting an automated version control

system like Git, we can keep our work neatly organized and

our changes safely coordinated with one another, all without a

lot of eort—that is, once we adopt and learn how to use such

a system.

HUMANS, MEET GIT

Git does for version control what web standards have done for

our code or, for that matter, what Microsoft Word has done for

word-processing documents. Because Git is so ubiquitous, once

15THINKING IN VERSIONS

Git is a decentralized version control system. Both your work-

ing copy and a complete copy of the entire history of the project

reside on your machine, the server, and every other computer

that hosts a copy of the project. By default, Git’s hidden repos-

itory folders live inside a visible working copy folder. If you

browse that directory, you’ll see only the les and folders you

expect to see in a working copy of your project. This working

folder is where you’ll make your changes.

Whenever you’re ready, you can easily move changes into the

safe, stable repository by making a commit. In our semi-manual

process, we “committed” a new version by making a copy of

our working copy, naming it with the next sequential version

number. Committing changes in Git is, conceptually at least,

very similar. For each commit, Git records the precise state of

our les as they are right now in the repository for later access

and retrieval. Unlike in our manual example, where we had the

annoying (and potentially risky) responsibility of making sure

new versions were copied into place correctly without clobber-

ing anyone else’s eorts, Git automates all of that busywork.

Even better, Git copies new versions incrementally, making

references to existing copies of les that haven’t changed to

conserve disk space.

Git not only takes care of safely copying data back and forth

between the working copy and the repository (and between

the local and server repositories), but it also provides a robust

system for referring to dierent versions of the project. One of

the small costs of establishing a manual version control practice

is needing to decide, and then communicate to your teammates,

the correct way to identify single versions. Should you use a

number (like v12), or a date stamp (2014-07-28), or something

else? Git allows you to assign your own names or numbers to

versions if you need to, but it also gives you a reliable, unique

identier for every single commit. If you don’t need to assign

custom names or numbers to versions, you can just sit back

and rely on Git to do that.

Finally, Git also oers powerful tools for safely merging

changes between different versions of a project—not just

between dierent collaborators, but also between multiple

variations of the project on one person’s computer.

剩余140页未读，继续阅读

森一郎

粉丝: 0
资源: 7

Git for Humans: Mastering Version Control for Web Creators

David Demaree-Git for Humans-A Book Apart (2016)

David Demaree-Git for Humans-A Book Apart (2016) 原版图书， 深入浅出介绍如何使用GIT

Visual-Studio-Code-End-To-End--editing and debuging for web developer.pdf

CMS.zip_0286cms18-b_apart1cf_cms_cms.vanwrd.c0m_cms系统划分

things_fall_apart--_full_text.pdf_tfa_ChinuaAchebe_ThingsFallApa

C.Plus.Plus.for.Engineers.and.Scientists.pdf

Deep learning for time series classification a review.pdf

A List Apart.txt

A Header Apart-crx插件

CCDE 400-007-en-unlocked.pdf

最新资源

David Demaree-Git for Humans-A Book Apart (2016) 原版图书，深入浅出介绍如何使用GIT