Совместная работа над документом#
Чтобы увидеть пользу от использования Git посмотрим на ситуацию из жизни, в которой она не используется и к каким сложностям это приводит.
Классический пример совместной работы над документом – это подготовка отчета, книги, диплома, статьи, учебного пособия. Начальную версию документа автор пишет самостоятельно или компонует из частей, написанных им и соавторами. Затем он получает обратную связь у заинтересованных сторон: соавторов, коллег, руководителей, рецензентов и редакторов. Автор обновляет свою версию документа, объединяя в нем полученные замечания и правки. Это повторяется до тех пор, пока все участники не достигнут компромисса. Основная тяжесть по сопровождению документа ложится на автора. Он должен сохранить логическую целостность документа и не потерять удачные куски текста.
Выделим следующие недостатки совместной работы над документом:
не видны правки;
теряются предыдущие версии документа;
теряется информация о том, кто, когда, что и зачем изменил;
затягивается работа из-за последовательного процесса редактирования.
Приведем способы борьбы с этими недостатками, которые может предпринять автор документа.
В двух версиях одного документа сложно, если вообще можно увидеть различия. Их можно найти, сравнивая в двух документах предложение за предложением. Это очень утомительно. Для решения этой проблемы, редактор “Microsoft Word” предлагает режим правок, при включении которого последующие редактирования текста выделяются визуально, одновременно сохраняя исходные состояния. Уже автор работает с правками, применяя или отказываясь от них.
Часто бывает, что рецензенты не редактируют присланный им документ, а делают замечания, привязывая их к номеру страницы и абзаца. Таким образом, автор сам редактирует текст по замечаниям.
После внесения правок предыдущая версия текста замещается новой. Редакторы поддерживают команду отката изменений (Ctrl-Z, Ctrl-Y), которая позволяет вернуть назад старую версию. Она применима только к тем правкам, которые были сделаны с момента последнего запуска программы.
Чтобы сохранить старую версию документа, делают ее резервную копию. В случае потери данных, например, из-за поломки диска, удаления или случайной перезаписи данных, данные восстанавливаются по последней копии. При этом потеряются изменения, которые были произведены с момента последней резервной копии, что лучше, чем потерять все. Резервное копирование часто применяют при подготовке офисных документов, когда следующая версия документа именуется в стиле “ОтчетНИР_15_Иванов.docx”, где в названии прописаны версия документа и автор правки. Такой подход хоть и страхует от потери документа, но требует соблюдения правил.
Следующий недостаток при совместной работе над документом состоит в том, что автору не доступна информация о том, кто, когда, что и зачем предложил изменить. Для небольших по объему и времени работы документов с единственным владельцем, это не так актуально. Информация содержится в электронной переписке, в резервных копиях файлов или в голове автора.
Слабое место при совместной работе над документом – это объединение правок от нескольких участников, которым приходится заниматься автору. Этот процесс утомителен и подвержен ошибкам. Чтобы обойти это, над документом работают последовательно. Каждый следующий участник работает над документом после предыдущего. Это растягивает время работы и слабо загружает участников. Это одна из причин, почему подготовка научной статьи растягивается на год и более.
Недостатки совместной работы над файлом не критичны применительно к офисным документам. В их подготовке лежит принцип личной ответственности автора. За такое старание он будет вознагражден первым присутствием в списке авторов. Замечания вышестоящего по должностной иерархии имеют приоритет над нижестоящим, что не позволяет распараллелить работу над документом. Жизненный цикл офисного документа длится до нескольких месяцев, так что недостатки над его работой можно перетерпеть.
По другому обстоят дела с разработкой ПО. Здесь во главу угла поставлена эффективность. Каждый разработчик загружен работой, выполняет ее в своем темпе, отвечает за ее качество и старается не мешать другим. При этом эффективность не должна теряться при масштабировании команды. Проблемы, возникающие при коллективной работе над разработкой ПО, как раз и решает Git. Git создана разработчиком (Линусом Торвальдсом) для разработчиков и проверена временем на огромных проектах с несколькими тысячами участников. Она может быть использована и другими специалистами, если их документы могут быть приведены к текстовым файлам.
Система контроля версий решает недостатки, свойственные совместной работе нескольких участников над проектом. Она:
показывает правки, внесенные в файлы;
сохраняет каждую версию файла;
связывает правки с информацией о том, кто, когда, что и зачем изменил;
обеспечивает параллельную и независимую работу над проектом.