LG.BALUKATION's Weblog

Ничего, это тоже кое-что… А при желании из него можно сделать что угодно

Метки и ветки

Posted by LG.BALUKATION на 2018/01/11

ВАЖНО: это статья для тех, кто только начал осваивать git. Тут будет рассказано о простых вещах, зато доступным языком (надеюсь). Так что не ждите откровений, тонкостей, секретных опций и т. п. Речь пойдёт об обычных вещах, которыми можно (и нужно!) пользоваться чуть-ли не каждый день.

Люди по разному приходят к системам контроля версий. Кто-то копирует проект в папочку время-от-времени и однажды просто ищет более продвинутый инструмент, чем архиватор. Кто-то другой правит раз в год конфиги и хочет понимать когда и откуда взялась та или иная опция… Вариантов много, главное что однажды человек решает всё-таки нормально отслеживать изменения и перестать страдать фигнёй.

Систем контроля версий существует целая куча. Какие-то из них старые, какие-то новые. У всех есть свои недостатки, у многих — преимущества. Сравнение и выбор наиболее подходящей — это отдельный разговор. Тут я всего-лишь предположу, что человек выбрал git. Гит на слуху — он весьма популярен, для него есть разные клиенты на любой вкус и цвет, его поддерживают известные сервисы, много популярного софта использует его для своей разработки.

Итак, человек решил использовать git. Он поставил какой-нить клиент, настроил всё сам себе или воспользовался каким-нить сервисом (самые популярные среди простых и бесплатных — GitHub и BitBucket) и начал потихоньку использовать. Создание репозитория и начало его использования обычно штуки простые — популярный сервис так вообще всё расскажет чуть-ли не с картинками как и что делать в самом начале. Так что я предположу, что настроенный репозиторий у человека уже есть, он туда просто коммитит иногда и даже пушит, если нужно.

Многие надолго останавливаются на этом этапе — ну а что, всё работает же! Однако, есть ещё пара важных вещей, которые стоит узнать как можно раньше. Конечно, без них можно кое-как существовать, но они просты и порой очень полезны. Не нужно бояться их.

Метка (tag)

Часто бывает нужно указать на какую-то конкретную «версию». Может быть, человек сделал обновление проекта. Может быть, тестировщики проверяют проект и нужно понимать — что они уже проверили, а что нет… Так или иначе, нужен простой способ помечать (а потом и находить) какие-то особые коммиты в истории.

Git устроен так, что коммиты он различает по их контрольным суммам. Зная эту сумму, коммит можно найти, но: контрольная сумма это набор букв и цифр, выглядящих для человека случайными! Её сложно запомнить, сложно кому-то сказать и даже просто напечатать кажется чем-то странным.

Конечно тут есть одна хитрость, которой часто пользуются — первые буквы и цифры в контрольной сумме повторяются очень редко, так что можно показывать человеку только их. Например вместо такой штуки:
commit d33828cf7d65a4e921278b51e31c6b81be6b13d0
можно показать лишь:
commit d33828c

Но это всё полумеры, коммиту можно дать нормальное название (например, «v1.07»). Это название большинство клиентов будет особо показывать в истории, его вообще можно будет использовать много где (например, переключится на последнюю проверенную версию или сравнить чем отличается «v2.00-beta1» и «v2.00-beta4»).

В общем метка, это что-то вроде понятного псевдонима для настоящего имени коммита (которое непонятный набор букв и цифр). Не бойтесь выделять среди своих коммитов важные и давать им нормальные имена!

Ветка (branch)

Ветками так или иначе пользуются все, даже те кто боятся пользоваться ими. Это сама суть гита — история изменений, цепочка коммитов. По-умолчанию гит создаёт одну ветку и называет её «master» — вот что значит это волшебное слово, иногда встречающееся в клиентах и командах.

Конечно, можно подумать «ну вот у меня есть какая-то одна история в ветке master, я там трогаю что-то потихоньку, зачем мне больше одной истории и куча веток — что я с ними делать-то буду?». Есть несколько вариантов, когда такие штуки полезны.

Например, больше одного человека решают работать над одним проектом. Конечно, они могут стараться не мешать друг-другу, быть аккуратными, работать в разное время и т.п. Но это всё способы так себе (кроме аккуратности — она всегда хороша!). Можно просто взять и сделать каждому по ветке, помимо одной общей. Тогда любой спокойно будет работать в своей ветке, делать там всё что считает нужным и когда считает нужным, а время-от-времени просто синхронизировать свои изменения с главной веткой, общей для всех.

Кстати, при работе с гитом более чем на одном компьютере — каждый автоматически использует свою ветку. Даже если просто сделать репозиторий на каком-нить сервере и подключить его себе на компьютер — это уже будет две ветки (master на компьютере и master на сервере).

Другой пример — нужно сделать какое-то улучшение. Некоторые боятся коммитить, копят изменения и потом заливают одним комитом, в котором поменяно много чего разного. У этого подхода есть ряд проблем, среди них — т.к. все правки это один большой коммит, правки не различить между собой, так же в процессе внесения этих изменений нельзя откатится на промежуточное состояние и можно убрать только всё разом.

Лично я люблю делать много мелких коммитов по-поводу и без. Когда коммиты частые, маленькие и простые — их легко отслеживать, понимать где что менялось и могло сломаться… Так что я предпочитаю для отдельного улучшения делать отдельную ветку, спокойно там коммитить какое-то время и лишь когда всё заработает как нужно — вливать эту ветку в главную. Можно даже несколько разных изменений делать в разных ветках одновременно и не путаться в них.

Третий пример — так называемая стабилизация. Всё, что нужно для какой-то версии уже сделали. Хочется с одной стороны хорошенько протестировать и исправить найденные ошибки, а с другой — не мешать разработке новых версий. Тогда можно сделать ветку для релиза этой (почти) готовой версии и переносить в неё только исправления ошибок или исправлять ошибки прямо в ней (если ошибки нет в главной ветке). Подобный подход — держать специальную ветку для бета-тестов, в которую переносить только отдельные фичи, проверять их и потом переносить уже в ветку для релиза.

Четвёртый пример — разные версии одного и того же. Есть проект и нужно выпустить несколько его версий. Они почти одинаковые, но каждая с какими-то своими особенностями (перевод на другой язык? другая платформа? дополнительные или наоборот урезанные фичи? демо-версия? и т. п.). Тогда самое то завести ветки навроде: efigs и chineese; pc, ps4 и switch; ios и android; demo и full… Все основные изменения будут в главной ветке, а в дополнительных будет лишь несколько специальных правок по добавлению, удалению или переделке чего-то.

Можно найти разные применения более чем одной ветке, они помогают лучше понимать проект и упрощают многие действия в нём. Не бойтесь делать ветки и не сваливайте всё в одну кучу!

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s