Итак, у вас имеются настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта.
Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем и не под версионным контролем. Файлы под версионным контролем — это те файлы, которые были в последнем снимке состояния проекта. Они могут быть неизмененными, измененными и индексированными. Файлы не под версионным контролем — это все остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к фиксации.
Когда вы впервые клонируете репозиторий, все файлы будут находиться под версионным контролем и будут неизмененными, потому что вы только извлекли их из репозитория и ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как измененные, т. к. вы изменили их с момента последнего коммита. Вы индексируете эти изменения и затем фиксируете все индексированные изменения, а затем цикл повторяется.
При разработке прикладных решений «1С:Предприятия» вы оперируете не отдельными .xml-файлами, а объектами конфигурации, содержащимися в проекте, в панели Навигатор. Поэтому о состоянии того или иного объекта конфигурации вы также можете получить информацию в этой панели. Это основной источник.
Кроме этого, при фиксации изменений в панели Индексирование Git вы видите отдельные .xml-файлы, соответствующие тем или иным объектам конфигурации. Они имеют такие же обозначения. Это просто дополнительная информация.
Панель Навигатор входит в состав перспективы 1С:Enterprise. Рассмотрите различные состояния объектов конфигурации на примере документов.
Значок (НовыйДокумент) говорит о том, что это новый объект, который пока еще не находится под версионным контролем.
Значок (все документы, кроме Оплата и НовыйДокумент) говорит о том, что этот объект уже находится под версионным контролем.
Значок «угловая кавычка» (>) после пиктограммы объекта (ОперацияПоУчетуТоваров и НовыйДокумент) говорит о том, что это измененный объект.
Значок (Оплата) говорит о том, что это индексированный объект, то есть его файлы помещены в индекс.
Панель Индексирование Git стандартно входит в состав перспективы Git, но эта панель открывается автоматически и в перспективе 1С:Enterprise, когда вы выполняете .
В этой панели представлены уже сами файлы, хранящиеся на диске. В верхнем поле находятся измененные файлы, под ними — индексированные файлы. Для индексированных файлов, которые первый раз добавлены в индекс, используется специальный значок . А значком обозначаются индексированные файлы, которые уже находятся под версионным контролем.
Если вы только что клонировали репозиторий, то в панели Навигатор объекты будут выглядеть следующим образом. У веток, в которых объекты конфигурации находятся под версионным контролем, будут соответствующие значки (например, ). Ни одна из веток не будет иметь угловой кавычки рядом с пиктограммой. Это означает, что у вас чистый рабочий каталог. Другими словами, в нем нет измененных объектов, находящихся под версионным контролем. В панели Навигатор также не будет объектов, которые не находятся под версионным контролем. В противном случае они бы были отмечены соответствующими значками (например, ).
Кроме этого панель Навигатор сообщает вам, на какой ветке Git вы находитесь, и сообщает, что эта ветка не расходится с веткой в удаленном репозитории (нет стрелок вверх и вниз после имени ветки). Пока что это всегда ветка master, ветка по умолчанию; в этой главе это не важно. Более детально вы рассмотрите ветки и ссылки позже, в разделе Ветвление в Git.
Предположим, вы добавили в свой проект новый объект — справочник Сотрудники. Вы сразу же увидите свой новый объект вот так.
Понять, что новый объект Сотрудники не под версионным контролем, можно по значку на его пиктограмме . Такой статус означает по сути, что Git видит файл, отсутствующий в предыдущем коммите. Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите. Это предохранит вас от случайного добавления в репозиторий файлов, которые вы и не думали добавлять.
Вы хотели добавить справочник Сотрудники, так сделайте это.
И в панели Навигатор, и в панели Индексирование Git вы увидите, что справочник Сотрудники теперь индексирован.
Если вы выполните коммит в этот момент (Фиксировать), то версия объекта, существовавшая на момент добавления его в индекс, будет добавлена в историю коммитов репозитория.
Теперь модифицируйте объект, уже находящийся под версионным контролем. Если вы измените документ ПриходТовара и после этого посмотрите в панель Индексирование Git, то результат будет следующим:
Это означает, что файл, находящийся под версионным контролем, был изменен в рабочем каталоге, но пока не проиндексирован. Проиндексировать его можно разными способами:
Теперь файл проиндексирован и войдет в следующий коммит.
Предположим, что в этот момент вы вспомнили одно небольшое изменение, которое хотели сделать в документе ПриходТовара до коммита. Вы открываете редактор, вносите и сохраняете необходимые изменения — и вроде бы готовы к коммиту. Но посмотрите в панель Индексирование Git.
Что такое? Теперь файл ПриходТовара.mdo отображается как проиндексированный и непроиндексированный одновременно. Как такое возможно?
Эта ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы перетащили его в индекс. Если вы выполните коммит сейчас, то файл ПриходТовара.mdo попадет в коммит в том состоянии, в котором он находился, когда вы последний раз перетаскивали его в индекс, а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения команды Фиксировать.
Если вы изменили файл после добавления в индекс, вам придется снова добавить его в индекс, чтобы проиндексировать последнюю версию файла.
Возможно, общей информации о состоянии объектов конфигурации вам недостаточно. Возможно, вам хочется знать, что конкретно поменялось, а не только какие объекты были изменены. Скорее всего, вас будут интересовать два вопроса: что вы изменили, но еще не проиндексировали, и что вы изменили по сравнению с последним коммитом.
Вспомните ситуацию, которую вы рассматривали в предыдущем разделе. Вы изменили документ ПриходТовара, проиндексировали его и потом снова изменили. Если вы посмотрите в панель Индексирование Git, то увидите только состояние файлов.
Изменения объектов конфигурации удобнее анализировать в редакторе сравнения и объединения. Для этого вы можете воспользоваться контекстными командами в панели Навигатор. Эти команды можно выполнять как для всего проекта в целом, так и для отдельных объектов конфигурации.
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, нажмите ПриходТовара.
в контекстном меню документаНе меняйте стандартные параметры и нажмите Сравнить. Чтобы быстро развернуть строки редактора, установите курсор в первую строку, а затем нажмите и удерживайте стрелку вправо.
Здесь видно, что в рабочем каталоге длина номера документа была уменьшена с 9 до 4.
Если вы хотите посмотреть, что вы изменили по отношению к тому, что находится в репозитории, то можете в панели Навигатор нажать в контекстном меню документа ПриходТовара. Эта команда сравнивает ваш рабочий каталог с последним коммитом.
Здесь видно, что в рабочем каталоге была не только уменьшена длина номера документа, но и изменен тип номера, со Строка на Число. Эти изменения еще не помещены в локальный репозиторий.
Простейший способ зафиксировать изменения — это в панели Навигатор нажать в контекстном меню проекта. 1C:EDT откроет (если она еще не открыта) панель Индексирование Git, в которой вы увидите измененные и проиндексированные файлы. Все измененные файлы, которые уже находятся под версионным контролем, 1C:EDT самостоятельно добавит в индекс.
Все файлы, которые вы хотите зафиксировать, должны находиться в индексе, то есть в поле Индексированные изменения.
Чтобы добавить файлы в индекс, нажмите (Добавить все файлы в индекс) в командной панели;
Необходимой частью любого коммита является сообщение. Оно поясняет для вас и для других разработчиков суть выполненных изменений. Сообщение можно написать в произвольной форме в поле Сообщение коммита.
Теперь, когда ваш индекс находится в таком состоянии, как вам и хотелось, вы можете зафиксировать свои изменения. Для этого нажмите Фиксировать.
Итак, вы создали свой первый коммит!
Чтобы посмотреть содержание коммита, нажмите в контекстном меню проекта История, в которой на самом верху списка будет ваш последний коммит.
. Откроется панельЧтобы удобнее пользоваться панелью можете зафиксировать ее на экране — для этого нажмите иконку в правом верхнем углу панели.
Как видите, коммит содержит довольно много информации: в какую ветку вы выполнили коммит (master), идентификатор (9cb91de) и полную контрольную сумму SHA-1 у этого коммита, какие файлы были изменены, кто автор, кто коммитер и так далее. Запомните, что коммит сохраняет снимок состояния вашего индекса.
Несмотря на то что индекс может быть удивительно полезным для создания коммитов именно такими, как и хотелось, он на самом деле несколько сложнее, чем вам нужно в процессе разработки прикладных решений в 1C:EDT.
Поэтому при работе в панели Навигатор 1C:EDT помогает вам пропускать этап индексирования и автоматически индексирует каждый уже отслеживаемый на момент коммита файл, позволяя вам обойтись без перетаскивания его в индекс. Это очень хорошо видно, если в процессе разработки держать открытой панель Индексирование Git, в тот момент, когда в панели Навигатор вы нажимаете .
В то же время в вашем проекте могут находиться служебные файлы, которые не являются частью конфигурации, но которые вы также хотите индексировать и хранить вместе с конфигурацией. В этом случае для индексации и фиксации изменений этих файлов вы можете использовать панель Индексирование Git и ее команды для произвольного добавления файлов в индекс и удаления из него. После того, как необходимый вам набор изменений добавлен в индекс, вы можете зафиксировать его, нажав Фиксировать.
В отличие от многих других систем версионного контроля Git не отслеживает переименование файлов явно. Когда вы переименовываете файл в Git, в нем не сохраняется никаких метаданных, говорящих о том, что файл был переименован.
Если вы переименуете справочник Сотрудники в справочник Работники, то в панели Индексирование Git увидите следующее состояние файлов.
Фактически это означает, что Git удаляет файл справочника Сотрудники.mdo и добавляет вместо него файл Работники.mdo.
По материалам книги Pro Git (авторы Scott Chacon и Ben Straub, издательство Apress). Книга распространяется по лицензии Creative Commons Attribution Non Commercial Share Alike 3.0 license.