Advertisement
  1. Code
  2. Tools

Git для Дизайнеров

by
Read Time:15 minsLanguages:

Russian (Pусский) translation by Andrey Rybin (you can also view the original English article)

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

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

На самом деле, если вы занимаетесь веб-программированием, не важно, фронтенд или бэкенд, вы должны относится к этому ответственно: использовать контроль версий.


5. Признаки того, что вам давно нужен Контроль Версий.

  1. Вы не представляете вообще, что это такое, или зачем он вам может понадобится.
  2. Вы кодите локально, и вы не используете бэкап.
  3. Вы случайным образом делаете бэкапы, при этом копируете основную директорию.
  4. Вы случайно полностью удаляли файлы, и приходилось все восстанавливать с нуля.
  5. После ряда редакций, ваше приложение перестало работать, и вы долго и с болью удерживаете Command + Z и смотрите, как редактор отменяет ваши правки.

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


5 Несомненных Преимуществ Контроля Версий

  1. Случайно удалили класс или файл-PSD? Напишите в терминале всего одну команду для возвращения к исходному состоянию проекта.  Так вы избежите разочарований!
  2. У вас замирало дыхание в ужасе, от того, что ваш сайт исчез с рабочего стола? Он был здесь вчера, а теперь его нет! Бесплатный сервис GitHub, избавит вас от этой проблемы.
  3. Кто же написал это код, который теперь надо исправлять часами? Нет нужны гадать, кто это сделал; Git все вам расскажет!
  4. Кодить без оглядки, при этом зная что, каждое ваше изменение будет записано,  на случай если вам нужно будет откатиться назад.
  5. Если эти причины не убедительны, примите то, что многие опытные разработчики считают это хорошей практикой. А это правильно подражать тем, у кого мы хотели бы учиться.

Git?

Git - это наиболее популярная и доступная система контроля версий.

Итак, как же Git контролирует всю эту ситуацию? Что ж, все дело в том, что Git - это распределенная система контроля версий, разработанная Линусом Торвальдсом, где каждый рабочий каталог представляет собой собственный репозиторий с полной историей, доступной в любой момент. И более того, Git, дает возможности делиться кодом, делать одновременно различные ветки верский (или различные по времени), что являетя очень удобных для команд разрабочиков использующих технологию agile.

Более понятным определением может быть следующее: Git -  это инструмент в командной строке, который вы и другие  разработчики в вашей команде,  используете для того чтобы сохранять снимки-снапшоты вашего проекта. В любой момент, он позволяет откатиться к более ранним состояниям, используя всего лишь одну команду.

Книга Скота Чакона 'Pro Git' - полностью доступна на веб-сайте Git.


Установка Git

Естественно, первым шагом, восстановления после того как поработали Настоящие Ковбои (Cowboy Coding - автономное кодирование) - это скачать Git с сайта git-scm.com. Используйте нужную вам ссылку в зависимости от используемой операционной системы.

  • Mac: https://git-scm.com/download/mac
  • Windows: http://git-scm.com/download/win

Потом нам нужно быстренько настроить конфигурацию, что очень просто, задав имя пользователя и электронный адрес. Откройте консоль (терминал на Mac) и запустите команду:

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

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

Поздравляю, теперь Gti успешно установлен!


Основной Цикл

Как и в любой новой технологии, придется кое-что подучить.

Один из самых сложных аспектов в изучении Git - это изучение терминологии. Коммит? Staging? Ветка? Логи?

Как и при работе с любой новой технологией, придется немного поучиться. К счастью, хоть Git может быть и труден, но вы, особенно, как веб-дизайнер, увидите, что вы будете пользоваться в основном небольшим набором команд. Для сравнения, возьмем словарь Английского, и посмотрим количество слов, которые мы используем в повседневной жизни. Тоже самое и для Git - но на гораздо более простом уровне. Так что не бойтесь перегрузиться теорией. Изучайте одну команду за раз.

Чтобы разобраться с этой запутанной терминологией, лучше обратиться к чему-то в реальном мире: грузовичок доставки.

Представьте, что вы начали делать новый статичный вебсайт. Вы создали папку для файлов Javascript и  CSS, а так же index.html файл, с начальным шаблоном  HTML. На самом деле сделайте это прямо сейчас! А когда закончите, сделаем первый коммит.

Вернитесь в Терминал и напечатайте там:

Это команда "инициализации Git", говорит Git о том, что мы хотим сделать контроль версий для данного проекта. Или "включить зажигание", и это нужно сделать только один раз, в начале нового проекта.

Теперь давайте определим "статус".

Если вы работаете со мной, то вероятно  вы увидите следующие строки:

Хотя сначала может быть непонятно, но если мы присмотримся, то мы увидим, что по умолчанию вы работает с "веткой" под названием "master" ("master branch"). Далее у нас есть один не отслеживаемый файл: index.html. И тут мы понимаем, что Git не волшебный и вообще-то ему надо указать на файл, который нам нужно отслеживать.

Интересно, а почему папки JavaScript и CSS не были включены в спискок не отслеживаемых файлов? Потому что Git отслеживает файлы, а не дирректории. Однако, общепринятой техникой является добавление файлов .gitgnore в каждую пустую директорию. Но подробнее об этом позже.

Отслеживание Файлов

Чтобы отслеживать файл, мы должны добавить его к репозиторию, или установить наблюдение за ним.

Теперь, если мы вновь, посмотрим его статус, то мы увидим:

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

Имейте в виду, что мы еще на начали записывать изменения;  мы только обозначили в системе пару файлов. Чтобы начать делать снэпшоты и сохранять копии проекта, в текущем состоянии, необходимо сделать коммиты.

Выше, мы сделали новый коммит и добавили сообщение "First commit". Этим мы завершили наш превый коммит, и оставили запись, с копией проекта, которую можно восстановить.

Чтобы оценить изменения в работе, необходимо использовать новую компнду: "log".

Отлично, мы создали новый коммит и он имеет уникальный id. С учетом новой редакции.

Если вы снова проверите статус.

Поскольку не было сделано новых изменений с момента последнего коммита, то Git скажет нам:

Ура! 90% использования Git, для этого этапа вы уже усвоили.

  • Сделайте изменения
  • Добавьте файлы в репозиторий
  • Сделайте коммит с записью описывающей ваше новое действие

Закрепите и повторите!

Теперь давайте прейдем к следующему шагу. Рассмотрим простой пример, допустим мы решили добавить простую таблицу стилей к нашему проекту. Мы напишем самый типовой файл.

Теперь, вернитесь в index.html, и добавьте ссылку на этот файл:

В качестве практического правила, запомните следующее, если вы можете описать человеку, сидящему рядом с вами, какие изменения вы только что внесли в проект, то они, вероятно, заслуживают коммита. Делайте коммиты чаще. Давайте сделаем это сейчас; обратно в Терминал!

Когда вы пишите название для коммита, принято писать его в настоящем времени. То есть пишем "добавляем файл" вместо "добавили файл".

Дайте представим, что у нас происходит дальше, допустим, ваш босс говорит вам, что он не хочет использовать простой файл сброса (reset.css) который вы сделали. Вместо этого, он хочет использовать популярный Normalize stylesheet, сделанный Nicolas Gallagher.

Без проблем; с Git, это сделать очень просто. Давайте вернемся к предыдущему коммиту, и сделаем необходимые изменения.

При работе с Git, есть такое правило "никогда не переписывайте историю".

По сути эта команда отменяет все изменения, которые вы сделали с момента последнего коммита. По сути она делает противоположные действия предыдущей команде. Почему мы отменяем действия, а не переписываем заново коммит? Потому, что мы с самого начала, стараеся следовать правильной практике. Правило Git гласит - "никогда не переписывайте историю". Возвращайтесь к исходному состоянию, но не удаляйте или не отменяйте уже сделанные изменения.

Перед тем, как вы нажмете ввод, вам будет показан новый экран с текстом "Revert "Add and include reset stylesheet."(Отменить и включить новый файл сброса). Теперь вы находитесь в режиме Vi (хотя вы можете использовать с Git любым текстовым редактором, с каким пожелаете). Теперь, оставьте все по умолчанию, сохранитесь и выйдите. Завершите все, напечатав, :wq (Write and Quit - Записать и Выйти).

И спомощью только одной этой команды, изменения будут отменены. Посмотрите и убедитесь в этом. Файл style.css  удален, и теперь нет ссылки на файл стилей в index.html. В этом сила Git! Поскольку мы при работе используемы частые коммиты, если возникает ситуация, когда нам нужно  отменить редактирование, мы делаем это с помощью одной команды. Теперь больше не надо долго и упорно давить на Command-Z!

Тепреь давайте, следуя пожеланиям начальства, изменим проект включив, скачанный файл Normalize.css в папку css/normalize.css.

А так же изменим ссылку в html фале:

И наконец создадим коммит для этих изменений.

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


Поле для Экспериментов

Сталкивались вы с такой ситуацией в проекте, когда вы хотите попробовать какую-то идею, но еще не знаете войдет ли она или нет в окончательный проект. Хотя вы всегда можете использовать коммиты и отменить изменения, если что-то пойдет не так, гораздо правильнее, по ряду причин, использовать вместо этого ветки.

Лучший способ проиллюстрировать концепцию веток в Git, это обратиться к фильму Назад в Будущее 2.

Одно замечание, если вы опытный разработчик, но еще не смотрели трилогию Назад в Будущее, прекратите делать все, что вы делаете и идите смотреть этот фильм!

Тепрь продолжим, помните ту часть в Назад в Будущее2, после того как Марти и Док, вернулись назад в 1985 год из будущего, и увидели, что все изменилось?  Там при встрече, в разрушенной лаборатории Док нарисовал диаграмму и объяснил, что " в какой-то момент линия времени пересеклась и  создалась альтернативная реальность 1985 года. Это как ветвление!

Давайте рассмотрим наш демо проект; сейчас у нас одна линяя времени: прямая линия. После того, как мы создаем ветку, для нашей рабочей идеи, мы обрываем эту линию вермени, и создаем новую. С этого момента, существуют две верменные линии, и каждая содержит свои соответствющие коммиты, и они не пересекаются друг с другом.

В чем тут для нас польза? Представьте agile разработку - когда вы и ваша команда делаете деплой обновлений несколько раз в неделю (под деплоем здесь имеется в виду развертывание сайта на сервере). Если вы используете подход с "одной линией времени", например, деплой, после исправления одной простой ошибки, будет невозможен, пока вы не закончите так же работать со своей идеей. Однакое, если вы используете ветвление, то у нас есть возможность рабоать с нашей идеей сколько угодно,  в то время, как мы можем работать с мастер веткой (по умолчанию и первичной) для деплоя после исправления ошибки.

Для создания новой ветки, напишите следующее:

Или как вариант, вы можете объединить эти команды в одну.

Словами это можно сформулировать так: создать новую ветку, с названием "идея"(лучше конечно описать более точно, над чем вы рабтаете), и переключиться на нее.

С этого момента, все модификации и коммиты, которые вы будете делать, будут относиться не к мастер ветке. Давайте, попробуйте, сделайте это. Отредактируйте idex.html и внесите небольшие изменения:

А теперь сделайте коммит.

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

После того, как мы закончили работу с нашей идеей, самое время вернуться назад и сделать объединение с нашей мастер веткой.

Если все сделано правильно, ваша дополнительная ветка, будет успешна объединена со старой мастер веткой, решив проблему альтернативной реальности 1985 года!

Хотя, бес сомнения, у вас будут случаться ситуации, когда Git будет вставать в стопор и отказываться делать так, как вы его просите. В таких случаях, Git ругается не без причины! Вероятно, что где-то существует конфликт, который необходимо решить, прежде чем Git сможет выполнить свою работу. Предположим мы пытаемся объединить файл с мастер веткой; проблема может быть в том, что с момента создания дополнительной ветки, файл мог редактироваться как в дополнительной ветке, так и в мастер ветке. В такой ситуации, откуда Git может знать, какая ветка будет главной при объединении и с какого момента начинать объединение? Ему это непонятно, и в таком случае возникает конфилкт.

Прежеде чем Git сможет продолжить работу, вы должны исправить конфликт, и отредактировать index.html.


Игнорирование Файлов

Очень вероятно, что со временем, у вас может возникнуть ситуация, когда какой-то файл лучше не отслеживать с помощью Git. Напирмер это может быть файл . DS_STORE (с которым знакомы пользователи Mac), дирректории для компиляции, или временные вспомгательные файлы.

Это очень лекго делается в Git, с помощью .gitignore файла,  чтобы игнорировать определенные типы файлов. Чтобы попробовать, сделайте новый файл .gitignore в корнеовой дирректории проекта (но не обязательно только так). Внутри фала, содайте список файлов или типы файлов, которые нужно пропустить. Вот пример:


Социальнаая сеть для программистов

GitHub делает возможным делиться кодом, по принципу социальной сети.

Итак, вы научились коммитить ваш код на машине локально. Но как вы можете поделиться этими изменениями с другими членами вашей команды или  с остальным миром? Используйте GitHub.

GitHub позволяет вам поделиться вашим кодом со всем миром. Это самое большое опенсурс сообщество.

После того как вы создадите новый аккаунт на github.com, вам понадобится сделать еще несколько шагов, чтобы сгенерировать специальный ключ, для того что-бы привязать ваш компьютер к GitHub аккаунту. Не беспокойтесь; если вы будете следовать рекомендуемым шагам, то все будет нормально.

Теперь мы должны создать новый реппозиторий, и  поместить в него наш маленький проект, чтобы поделиться им с миром. После того как вы войдете в свой акканут, щелкните по кнопке "New Repository", дайте ему имя, и нажмите на "Create Repository." Затем вам будет предложено несколько команд, которые вы должны будете ввести в терминале. Так как у нас уже есть созданный реппозиторий, то нас интересует второй вариант:

Это инструкции для Git, чтобы он добавил наш новый удаленный реппозиторий и назвал его "origin". Далее мы связываем нашу мастер ветку (не ту которая с идеей) с удаленной с названием "origig".

Вот и все!  Вернитесь в браузер, обновите страницу, и вы увидите свой новый репозиторий, который так и ждет, чтобы им поделились с миром.

Когда члены вашей команды захотят вытащить себе изменения в вашем проекте, то им для этого нужно записать команду:

Это команда позволяет извлечь последние изменения, которые были опубликованы на GitHub! Кроме возможности делиться кодом, GitHub, также дает возможность отслеживать и распространять изменения в популярных открытых проектах, а так же ослеживать решения багов и запросов в ветках. Это совместный кодинг в лучших своих проявлениях!


Мысли под конец

Хотя мы буквально затронули самую малость из того, что может Git, на самом деле, в этой статье мы рассмотрели на 80% то, что вы будете использовать в своей работе. Создайте ветку, напишите код, добавьте его в реппозиторий, напишите коммит с названием. Когда все готово, вернитесь к мастер ветке и сделайте деплой! Пробуйте и повторяйте!

Не забывайте: если вы запутались,  StackOverflow - ваш лучший друг. Какая бы проблема у вас не была, наверняка другие с ней сталкивались. Попробуйте поискать ответ.

TryGit  предлагает возможность поизучать Git интерактивным образом

Дальнейшее чтение

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.