Скотт Чакон - Pro Git

Интересная возможность атрибутов Git, которая может вам пригодииться, заключается в указании файлов, которы следует считать бинарными (особенно, когда определить это не представляется возможным), и определении инструкций как именно Git должен обрабатывать эти файлы. Например, некоторые текстовые файлы могут генерироваться автоматически и отследить изменения в них невозможно, в то же время, отследить изменения некоторых бинарных файлов вполне возможно. Далее вы увидите как объяснить Git где какой файл.

Некоторые файлы выглядят как текстовые, но работать с ними нужно как с бинарными данными. Например, на Mac в Xcode проекте содержится файл с расширением .pbxproj, который генерируется IDE, содержит различные настройки проекта и сохраняется в формате JSON (текстовое представление Javascript данных). Технически - это текстовый файл (потому как все данные в UTF-8), фактически - легковесная база данных; отслеживание изменений в нём бесполезно, а слияние изменений - сделанных двумя людьми - невозможно, поэтому вы вряд ли захотите обрабатывать его как текстовый файл. Файл предназначен для чтения машиной, а не человеком. Вот почему его следует рассматривать как бинарный.

Чтобы Git начал обрабатывать все pbxproj файлы как бинарные, добавьте в файл .gitattributes следующую строку:

*.pbxproj binary

Теперь, Git не будет конвертировать или исправлять CRLF в этом файле; не будет пытаться определить изменения или выводить их на экран при выполнении команд git show или git diff.

Возможности атрибуты Git так же можно использовать для эфективного сравнения бинарных файлов. Сделать это можно указав Git каким образом конвертировать бинарные данные в текстовый формат, чтобы затем сравнить их обычным способом.

Этот подход решает одну из самых досадных проблем, известных человечеству: контроль версий документов Microsoft Word. Все уже знают, что Word - самый ужасный редактор из всех, но, как ни странно, продолжают его использовать. Если вы хотите контролировать версии документов Word, то поместите их в Git репозиторий и периодически делайте коммиты; но как это решает проблему? Если вы просто выполните команду git diff, то увидите следующее:

$git diff

diff --git a/chapter1.docx b/chapter1.docx

index 88839c4..4afcb7c 100644

Binary files a/chapter1.docx and b/chapter1.docx differ

Нельзя просто взять и сравнить два файла не читая их и не сравнивая вручную, так? Это становится возможным при использовании атрибутов Git. Добавьте в файл .gitattributes следующую строку:

*.docx diff=word

Это говорит Git, что нужно использовать фильтр “word” при просмотре изменений файлов, соответствующих шаблону .docx. Что такое “word” фильтр? Вам следует его настроить. Нужно сконфигурировать Git на использование программы docx2txt для конвертации документов Word в текстовые, которые можно корректно сравнивать.

Для начала, нужно установить программу docx2txt; вы можете скачать её здесь http://docx2txt.sourceforge.net. Следуйте инструкциям из файла INSTALL для её установки и настройки запуска из командной строки. Затем следует написать скрипт обёртку для конвертации вывода программы в формат, понятный Git. Создайте файл docx2txt в любом доступном для запуска месте и добавьте в него следующее содержимое (прим. пер.: применимо для Linux и Mac):

#!/bin/bash

docx2txt.pl $1 -

Не забудьте добавить права запуска для созданного файла. Наконец, настройте Git на использование созданного скрипта:

$git config diff.word.textconv docx2txt

Теперь Git знает, что при сравнении снапшотов содержимое файлов .docx должно быть предварительно обработано фильтром “word”, который определен в программе docx2txt. Для каждого файла Word создаётся его текстовая версия.

Для примера, первый раздел этой книги был сохранен в формате Word и добавлен в Git репозиторий. Затем был добавлен новый абзац. Вот что покажет команда git diff:

$git diff

diff --git a/chapter1.docx b/chapter1.docx

index 0b013ca..ba25db5 100644

--- a/chapter1.docx

+++ b/chapter1.docx

@@ -2,6 +2,7 @@

This chapter will be about getting started with Git. We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so.

1.1. About Version Control

What is "version control", and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.

+Testing: 1, 2, 3.

If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.