Начинаем использовать систему контроля версий tortoisehg(mercurial) - commit

Часть 1: Установка/настройка

Вообще говоря, в системе контроля версий, всего 3 основных рабочих окна:
  1. Окно коммита
  2. Окно просмотра репозитория
  3. Окно merge

Они, в свою очередь, они могут вызывать множество второстепенных диалогов. Их мы будем рассматривать по мере надобности.

Сегодня мы поговорим о Commit-e.

Commit:
Ну репозиторий это хорошо, но в него надо что-то положить…
Жмем кнопку: Commit. Это отдельное окно, для добавления изменений.


Интерфейс:
Вверху необходимо дать описание к комиту
Внизу слева — список файлов.
Синим цветом подсвечен измененный файл под контролем (был раннее закомичен)
Красный файл — в новом комите пропал (удален)
Остальные файлы не под версией и не в игноре (см. ниже)
Если файл только добавлен — то он будет зеленым.
Галочками можно выбирать те файлы, изменения в которых войдут в этот комит. Сейчас будет подтверждено изменение только в одном файле. Удаление файла PCB-prepare.txt не будет отражено в репозитории.

Под списком файлов: набор галочек — какие файлы показывать/не показывать.

Внизу справа анноттация к изменению. там 3 вкладки:
1) Tex Diff — разница, которая будет закомичена для выделенного файла.
Разница в файле
Видно что были закоментированы 2 строки
2) Hunk Selection — там каждое измение будет в отдельном баре. Можно выбрать какие изменения должны войти в этот комит. Поясню на примере:
Переделываете вы код, допустим добавляете новую фичу. И тут заметили баг в старом коде. Исправляете и идете дальше. В момент коммита хорошо бы эти два 2 изменения разделить, т.к. они независимы. Исправление ошибки может понадобиться в других версиях, а новый функционал нет. Меркуриал позволяет в один клик перенести комит из версии в версию (из ветки в ветку). Вот мы и отмечаем сначала одни изменения — и делаем коммит. Потом остальное — и делаем второй.
Разные изменения
Коментарий ассерта войдет в этот комит.
Второе изменение не войдет. Переключение — дабл-клик на блоке.
3) Commit Preview — Полный сбор всех изменений по всем файлам, которые войдут в коммит.

В списке файлов, доступно контекстное меню. Если действие необходимо сделать с несколькими файлами, их можно выбрать используя shift и ctrl.
Контекстное меню
Возможные варианты действий:
1) Diff (доступен для файла под контролем) — покажет разницу между пред. версией и текущей. Аналогично — двойной клик на файл.
2) Edit — Можно редактировать любой файл. Иногда очень удобно, если нужно внести мелкую правку — а IDE открывать лень…
3) View missing (доступен для удаленного файла) — Можно посмотреть содержимое удаленного файла.
4) Revert (доступен для файла под контролем) — отменить изменения и восстановить состояние на последний коммит.
5) Annotate (доступен для файла под контролем) — можно посмотреть состояние файла по строкам — какая строка каким коммитом изменена/добавлена.
6) Forget — забыть файл находящийся под контролем.
7) Add — добавить файл под контроль.
8) Rename — переименовать файл. В случае переименования через систему контроля — вся история сохраняется. Можно смотреть изменения, переносить комиты. Система сама поймет — что файл сменил название.
9) Guess Rename — очень удобная система поиска переименования файла (см.ниже).
10) Ignore — добавить файл в игнор. (см. ниже)
11) Delete Unversioned — удалить файл который не под контролем с диска.
12) Commit — аналогично кнопке вверху слева — закомитить изменения.

.HGIGNORE:
.HGIGNORE — это специальный текстовый файл, который содержит настройки для игнорируемых файлов и каталогов.
Если не стоит галочка показывать игнорируемые файлы, то эти файлы не показываются в списке.
Мой файл выглядит так:
glob:Release/*
glob:Debug/*
glob:OvenControl.dep
glob:settings/Oven.wsdt
glob:*.bak

Игнорировать все в каталоге Release и Debug
Игнорировать файлы: OvenControl.dep, settings/Oven.wsdt
Игнорировать все файлы с расширением bak

Есть 2 вариант его изменения. Можно просто отредактировать в соответствии с форматом.
Или из контекстного меню выбрать Ignore и настроить все визуально:
Окно настройки списка ignore

Guess Rename:
Если необходимо переименовать файл, находящийся под контролем, делать это необходимо в системе контроля версий, т.к. она будет знать что в определенный момент файл сменил название, и будет корректно отображать историю файла. Но иногда удобно переименовать вне системы (например массово по шаблону), или еще по каким причинам. Тогда нужно как-то сообщить системе что мы сделали. Иначе, система решит что один файл удалили, новый добавили… Вот для этого и придумали отличный механизм: Guess Rename
Исходная ситуация — файл powerControl.cpp был переименован powerData.cpp:

powerControl.cpp — отмечен восклицательным знаком (и красного цвета) — файл удален.
powerData.cpp — отмечен вопросом — новый файл не под контролем.

Выделяем новый файл, жмем Guess Rename и получаем окно:

Слева список файлов не под контролем — кандидаты на переименованные файлы. Выделаем нужный (можно выделить сразу несколько файлов) и жмем кнопку Find Remanes. Система будет искать среди удаленных файлов наиболее похожий на новый. Минимальная степень «похожести» задается бегунком вверху (сейчас выставлена в 30.1%).
В итоге, найденные файлы отображаются справа:

С указанием степени похожести файлов (на скрине не уместилось 100%)
Выбираем файл, жмем Accept Match и выходим (если остались другие фалы — поступаем аналогично).

Как видим:
powerControl.cpp — отмечен знаком «R» — файл переименован.
powerData.cpp — отмечен знаком «A» — добавлен.
ЗАМЕЧАНИЕ: если вы ошиблись, то просто «забываете» новый файл (команда «Forget») и проводите процедуру снова.

Diff
Предварительное замечание: Diff — это простейшая разновидность Merge — слияния нескольких версий файла в один — итоговой.
Подробно, все возможные виды Merge, будут рассмотрены в отдельной статье. Сейчас будет краткое описание интерфейса (будем двигаться постепенно).

При работе Diff — всегда присутствуют 2 или 3 разные версии файла. В данном случае 2: старая и текущая.
Каждая измененная строка имеет маркер справа — рядом с полосой прокрутки. Разным цветом — отмечены разные изменения.
Вверху есть кнопки — отображения изменения «пробельных» символов — «пробел», «таб» и т.д.
Над каждым файлом указан его путь в РЕПО и его ревизия.

Пока по окну Diff/Merge — все.
В след. части — мы будем работать с Merge.

Комментарии (16)

RSS свернуть / развернуть
По сравнению с TortoiseSVN, эта программа местами выглядит так, как будто ее поклонники CLI писали :) В частности, тектовые диффы.
KDiff3 — одобряю. Но для диффа я предпочитаю WinMerge — есть подсветка синтаксиса и редактирование текста.
0
  • avatar
  • Vga
  • 14 февраля 2015, 13:42
В настройках можно менять тулу для merge/diff. Это не проблема. Мне KDiff3 больше всего нравиться, потому я его не трогаю и про него пишу.
Про CLI не понял… :(
0
В настройках можно менять тулу для merge/diff.
Я в курсе. Просто рекомендую попробовать WinMerge 2 как 2-way diff.
0
Про CLI не понял… :(
Ну, например, вместо текстового диффа мог бы быть графический — примерно как в Diff3 измененные блоки показываются/выбираются.
В общем, во многом чувствуется веяние команднострочного интерфейса, несколько неуместное в гуе. В TSVN такого нет, там чисто гуевый подход.
0
*KDiff3
0
QuaziKing2 молодец, так держать! Но есть маленькое не то чтобы замечание, но скорее предложение — в ближайших статьях добавлять больше практических ситуаций и их разрешения, каких-то неявных особенностей, советов.
По моему скромному мнению, понять идеологию работы с программой гораааздо проще по живому примеру. Т.е. когда параллельно с объянениями тебе сразу накликивают мышкой на экране все то, о чем говорят (особенно когда в живую). Например, вот замечательный курс из 6 видео, в котором автор объясняет от и до как работать с черепашкой на примерах (притом показывает все операции с двух сторон — терминал и гуи). Затронуты все основные вопросы — от причин пользования такой системой до разработки в команде через bitbucket. 1,5 часа просмотра достаточно, чтобы, зная все основы, вовсю начать применять Hg. И вот тут вот, как раз бы пригодились советы от более опытных товарищей, модели оптимального поведения в разных ситуациях и прочее.
+1
И еще хотел спросить. Касаемо стиля работы. Получается что при работе с исходными кодами, мы смело можем отпочковывать ветки, сливать их обратно если надо, разрешая попутно конфликты. А как быть при работе с нетекстовыми файлами — приниципиальные схемы, рисунок ПП, другие графические файлы? Тут получается, что мы можем работать только вдоль одной ветки, и если мы вдруг из какого нибудь коммита создадим еще одну ветку, то обратно они уже никогда не сольются, верно? Т.к. смержить 2 файла Diptrace, например, нереально.
Умозаключаю, что оптимальным вариантом является сделать один репо на коды, другой на плату со схемой, чтобы их коммиты не мешались друг другу. И в черепашке их объединить в одну группу, чтобы было удобнее. Я так понимаю?
P.S. Про субрепо читал поверхносто, и пока что они меня отпугивают, чую что проблем могу огрести.
P.P.S. QuaziKing2 в статьях ты показываешь репозиторий печки, как у тебя там в целом все организовано?
0
Бинарные и подобные файлы придется мержить ручками, да. Тебе VCS выдаст три версии (твоя, их, базовая), после чего — сливай как умеешь.
В принципе, с такими файлами иожно работать через механизм локов, собсна, для этого он и сохраняется в современных VCS.
0
В печке у меня лежали только код прошивки. Все остальное лежало отдельно.
в ближайших статьях добавлять больше практических ситуаций и их разрешения, каких-то неявных особенностей, советов. По моему скромному мнению, понять идеологию работы с программой гораздо проще по живому примеру.
Все скрины сделаны с реального РЕПО. Все особенности я описываю.
Касаемо стиля работы.
Я бы не стал разделять код и все остальное. Очень сложно сопоставлять версии.
Мержить ветки НЕ НУЖНО. Ветка — это независимая версия. Комиты между ними переносятся точечно, без merge веток.
Да. Бинарные файлы придется просто копировать как есть из одной ветки или другой — но целиком.
0
Я бы не стал разделять код и все остальное. Очень сложно сопоставлять версии.
Т.е. коммитим изменения по текущему устройству в одной ветке(код+плата). А если надо будет переделать плату под другой корпус, и чутка подправить функционал, то возвращаемся к какому-нибудь удобному коммиту и отбранчевываемсяв другую версию устройства, где ведем соответсвующие разработки?
0
Ветка это ветка. В ней можно отдельные фичи разрабатывать, можно хранить вариант прошивки, сильно запиленный под какие-то условия, а можно держать сайт проекта.
0
Мержить ветки можно и нужно! :) Если в них разрабатываются фичи, например.
0
Я понимаю, зачем ветка в принципе и какие потенциальные профиты она может принести. И мне более-менее понятно как организовывается работа с кодом в этой системе. Но мне пока непонятно, как организовать свою работу в целом, где окромя кода, в проекте присутствуют куча других бинарных файлов, версионность которых тоже хотелось бы иметь.

Лучше я приведу сферический пример. Есть некий разработчик Вася, который захотел сделать себе логгер уличной температуры с отправкой данных в комп по UART-USB 24/7. Вот такой вот температурофил, да. Он как четкий пацан естественно пользуется системой контроля версий для разработки — создал репозиторий, в который по папочкам свалил код, схемы, печатки. Вообщем разрабатывает себе, разрабатывает — нарисовал схему, написал кода, подправил схему и еще написал кода, протрассировал плату, написал кода, ну вообщем все как положено. Все это дело он, естественно, щедро закоммичивает в процессе, отбранчевывает фичи, мерджит их потом обратно и все такое. Сделал он устройство, отладил — работает. Пришел к нему в гости программист Петя, как увидит это чудо техники, да как загорится сделать термометр для своих кактусов на балконе. Вообщем дергает он за рукав Васю, да просит чтоб тот ему за магарыч такой же сделал, но чтоб данные по блюпупу слались, а замеры происходили ровно каждую 13ю секунду 7ой минуты каждого нечетного часа. А что с показаниями на пк сделать — Петя и сам разберется.

Знатоки, внимание! Вопрос: как Васе с минимальным геммороем помочь Пете, используя свою систему контроля версий? Или может быть Васе стоит организовать изначально организовывать свои разработки несколько по другому? Если да, то как?
0
где окромя кода, в проекте присутствуют куча других бинарных файлов, версионность которых тоже хотелось бы иметь
Да она, тащемта, и так есть. Недоступно только автоматическое слияние. Лично я с бинарными файлами работаю точно так же, как и с сырками. У меня, правда, SVN, где от автомерджа и так толку нет.
А вот на вопрос не отвечу. В SVN это как раз бранчем делается, хотя перекидывать общие изменения между ветками будет, вероятно, геморройно, а вот как это делается в DVCS я и сам охотно послушаю.
0
Предназначение немного не то.
Петя пришёл, захотел доработать проект под себя. Склонировал репу себе. Дальше варианты.
  • * Петя будет следить за проектом Васи. Петя делает отдельную ветку, что-то вней меняет и пользуется. При обнаружении изменений в проекте Васи, Петя обновляет исходную ветку склонированного проекта и ребейзит свою ветку на обновлённую от Васи, чтобы задействовать все его нововведения.
  • * Петя будет сотрудничать с Васей. То же, но + Петя отправляет Васе pull-request'ы с полезными для всех изменениями.
  • * Петя форкнул проект Васи и помахал ему ручкой. Петя просто изменяет что хочет у себя и никакой связи с проектом Васи более не будет. Хотя перехода к первому варианту это не исключает
  • ...

Если у вас бинарные файлы меняются и коммитятся часто, то есть являются самостоятельным проектом, их можно вынести в отдельный репозиторий и использовать как субмодуль. При этом основной проект будет иметь внутри каталог другого проекта, в конкретной его версии-коммите.
Инструменты Git — Submodules
Организация работы с git submodules
Внешние зависимости в гите: submodule или subtree?
0
Ага, теперь стало яснее. Про гитовский submodule, каюсь, не читал. А вот про Hg subrepo пробежался.
На деле все оказалось не так страшно. При каждом коммите главного репо делается снэпшот состояния субрепо. И при беготне по ревизиям основного репозитория, загружаются соответсвенно те состояния субрепо которые были в моменты коммитов главного репо. Вообщем, удобно получается вроде и отсутствует проблема, когда сложно сопоставлять версии (как писал выше QuaziKing2 ), т.к. ревизия кода жестко связана с состоянием субрепо печатной платы.
+1
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.