6 августа 2015 г.

[ЧЕРНОВИК] Git, Github и Github pages или "Маленькое чёрное платье"


У каждой женщины должно быть маленькое чёрное платье (c) Так и каждый уважающий себя web-разработчик должен уметь пользоваться такими инструментами как git и github.

Эта статья, назовём её второй, об азах работы с системой контроля версий. Первая вот здесь.
И как всегда один нюанс - всё это дело под Windows (таково пожелание клиента :( ).

Немного теории

VCS (version control system) - система контроля версий, основная задача которой вести учёт всех изменений в коде проекта сделанных разными участниками. Она позволяет посмотреть всю историю изменений каждого файла (кто/когда/что).
Да, никто не мешает и одному пользоваться системой контроля версий - следить за самим собой. Да и основная цель использования системы контроля версий, в нашем случае - это разработка одного проекта из разных мест (дом-работа).

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

Популярные распределённые vcs:
Популярне централизованные vcs:
Git, к стати, изначально писался Линусом Торвальдсом (автором ядра Линукс), для хранения иходных текстов ядра, потому как его не устраивал тот теущий инструмент (не вспомню название), которым они пользовались до этого. Перевод интервью на Geektimes.

Подготовка

Сразу к практике.

Github

  1. Регистрируемся на https://github.com/
    GitHub - это условно-бесплатный хостинг git-репозиториев, который даёт ещё много приятных плюшек (вики, баги, пулл-реквесты, итд).
  2. Создаём новый репозиторий

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

Windows Git

MSYSGIT
Хоть Git и был написан под Linux-ом для использования под Linux-ом, но всё же есть более-менее адекватный варинат под Windows https://msysgit.github.io/index.html.
Cкачиваем, устанавливаем. Next > Next > Next.
Можно остановить внимание на следующих скринах:

"Направо пойдёшь, коня потеряешь" (с).
  1. использовать git только из собственной коммандной строки;
  2. использовать git ещё и в системной коммандной строке (та, которая cmd);
  3. использовать git и кучу Unix-овых утилит в коммндной строке Windows (перепишет стандартные встроенные).
Рекомендую либо первый, либо второй пункт. Если не будет желания ковырять консольные комманды git - то первый, если будет - то второй.

Line-end-инги - попаболь и холивар всех времён:
  1. Чекаут - windows style (CR+LF), коммит в репозиторий в Unix style (LF);
  2. Чекаут как есть, коммит в Unix style;
  3. Чекаут как есть, коммит как есть.
(по простому: Windows использует два символа для переноса строки, а Unix-семья - один).
Рекомендую второй.

Далее он попросит около 100 Мб свободного места и притащит с собою друганов - разные полезные unix-утилиты (mingw).

TortoiseGit
И для облегчения жизни новичкам советую доустановить TortoiseGit https://code.google.com/p/tortoisegit/. Он даст более наглядное представление что происходит и более тесную интеграцию с проводником Windows.
Устанавливаем методом Next > Next > Next.

Необходимо выполнить первоначальную настройку утилиты. К настройкам TortoiseGit можно добраться либо из контекстного меню TortoiseGit > Settings, либо из меню "Пуск"


Необходимо указать своё имя и адрес электронной почты (просто для справки).

Public/Private Keys

Для дальнейшей работы с внешним репозиторием Git (GitHub), необходимо сгенерировать пару публичного и приватного ключей. По этой паре ключей внешний репозиторий (сервер) сможет вас опознать со 146% точностью.

Для этого в меню "Пуск" необходимо найти и запустить PuTTYgen.


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

 

Здесь можно изменить название (комментарий) ключа и задать пароль (пароль можно и не указывать, на свой страх и риск).

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

Жмём кнопки Save public key, Save private key и сохраняем ключи. Желательно использовать директорию %HOME%/.ssh (напр. C:/Users/Anton/.ssh).

Теперь в меню Conversion > Export OpenSSH key и выбираем каталог (тот же).

Рекомендуемые имена файлов (чтобы потом меньше проблем было):
  • публичный ключ: id_rsa.pub
  • приватный ключ PuTTY: id_rsa.ppk
  • приватный ключ (стандартный ssh): id_rsa

Теперь можно скопировать пуьличный ключ из верхней секции (он совпадает с сохранённым) и добавить его в список авторизированных на GitHub (верхний правй угол > Settings > SSH Keys > Add SSH Key), название (title) может быть произвольным.

Можно закрывать генератор.

А теперь все вместе

Попробуем завести теперь это всё вместе. Для этого на GitHub-е откроем созданные раннее репозиторий, найдём в правой части URL, по которому можно достучаться до него:


скопируем адрес

Далее вызываем контекстное меню в необходимом каталоге 'Git Clone...'


Здесь можно изменить создаваемый каталог (будет соответствовать названию репозитория) и необходимо указать путь к приватному ключу (созданному раннее).

Если к ключу был задан пароль - здесь его попросят ввести.

Далее нам предложат запомнить этот сервер как доверенный (ему можно доверять).


Готово.

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

Git и TortoiseGit

Добавим несколько файлов в каталог.
Теперь для того, чтобы добавить их в индекс репозитория, необходимо git-у об этом явно укзать - самое проще из контекстного меню по файлам/каталогу.


Здесь либо Git Add all files now, либо TortoiseGit > Add... Выбираем все файлы и Ок.

Теперь они находятся в индексе, и Git за ними следит.

Далее необходимо "закоммитить" изменения - сохранить в локальном репозитории. Это гарантия того, что ваши изменения останутся сохранены в репозитории.
Git Commit -> 'master'...


Желательно взять за правило ВСЕГДА оставлять комментарий о том, что коммитися. И один коммит на одно логическое изменение.

Эти изменения остались в локальном репозитории. Для того, чтобы отправить их на удалённый репозиторий (GitHub) необходимо выполнить операцию Push.

Это можно сделать сразу после коммита, в окошке отчёта:


Либо из контекстного меню Git Sync...


нажать на кнопку Push.

Всё, теперь эти изменения можно увидать в GitHub-е. .. и начать работать с ним.

Промежуточное заключение

Теперь свою работу в нескольких местах можно строить таким образом: на одном рабочем месте: Update (Pull), Commit, Commit, Push. на другом: Update (Pull), Commit, Commit, Push, и т.д.

Git

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

По-большому счёту следущая часть будет вольным переводом туториала https://git-scm.com/docs/gittutorial. Вместо него можно почитать что-то в роде http://rogerdudler.github.io/git-guide/index.ru.html на русском языке.
В дальнейшем большинство операций будет производится в консоли git, которая должна была установится вместе с MSYSGIT и быть доступна либо в меню пуск, либо в контекстном меню.
Отважным любителям консоли под Windows возможно будет интересно попробовать один из проектов улучшенного терминала:
  • ConEmu https://conemu.github.io/en/
  • Console2 (к сожалению единственное место, как оффициальный сайт указан SourceForge, который в последнее время протух, то ссылку на него давать не буду - без труда найдёте сами)
 Первое, что необходимо сделать, перед началом работы - указать Имя и e-mail, если этого не было сделано раньше:

$ git config --global user.name "Your Name Comes Here"
$ git config --global user.email you@yourdomain.example.com

Для создания новго репозитория (совсем нового), используется команда

$ git init

Теперь можно добавить желаемые файлы в папку репозитория (создать/скопировать/распаковать). И добавить их в репозиторий git

$ git add .

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

$ git add file1 file2 file3

Теперь эти фалы помещены git-ом во временное хранилище (index). Для того что бы добавленные файлы попали в репозиторий, необходимо выполнить

$ git commit

это перенесёт все содержимое идексов в репозиторий (сделает снимок) и запросит комментарий к коммиту.
Для того, что бы коммитить сразу с комментарием:

$ git commit -m '<your comment>'

По-идее это будет первые коммит, первый слепок репозитория.

Первые изменения
Можно создать несколько файлов и добавить их репозиторий.
Посмотреть разницу между последним закоммиченным слепком и текущим индексом:

$ git diff --cached

Та же комманда без --cached покажет изменения, не добавленные в индекс.

$ git commit -m '<message>'

добавит изменения в репозиторий.

Можно упростить путь помещения файла в репозиторий:

$ git commit -a

добавит файл и закоммитит сразу.

История изменений
Для просмотра истории коммитов
$ git log

ключ -p покажет и непосредственно сами изменения (текст) между коммитами:
$ git log -p

Ветвления
Ветвления (или бранчевания / бранчи) - это одно из самых основных инструментов git. Бранчи позволяют создать копию репозитория рядом с текущей версией, для каких-то изменений/экспериментов, а потом их объединить.
Варинатов использования этой возможности довольно много, на нём можно построить целый процесс разработки продукта. В этой статье описан один из них http://habrahabr.ru/post/106912/.

$ git branch

покажет список всех веток в текущем репозитории по-умолчанию основная ветка - master.
Для создания новой ветки необходимо выполнить следующую комманду:

$ git branch feature1

переключит репозиторий на ветку feature1

Далее можно внести некоторые изменения, закоммитить в ветке feature1 и объединить изменения с master:

$ git checkout master
$ git merge feature1

Тут можно удалить бранч feature 1
$ git branch -d feature1

Если буду не объединённые изменения, вас об этом предупредят. Для удаления ветки "без вопросов" необходимо использовать ключ -D

$ git branch -D feature1



-- ... --

GitHub Pages

Есть в GitHub такая замечательная функциональность, как GitHubPages - это возможность бесплатно крутить свою статику на GitHub, рядом со своим репозиторием.

В разделе своего репозитория, справа выбрать Settings > Options (первая секция) > прокрутить до GitHub Pages и нажать Launch automatic page generator. Далее можно не заморачиваться, Next > Next, выбираем шаблон, мне понравился Minimal. Тут без разницы какой выбрать, потом его всё-равно можно/нужно будет править. > Publish Page.

Теперь на удалённом репозитории для нас была создана отдельная ветка (gh-pages) со статикой, которую собственно, можно тепреь изменять как нам захочется. Это будет, в каком-то роде, визитной карточкой репозитория. Адрес, по которому GitHub будет хостить эту статику будет: https://<username>.github.io/<RepoName>, ну он там в любом случае напишет точный url, когда создаст.

Для того, чтобы переключить локальный репозиторий на другую ветку в TortoiseGit, выбрать в контекстном меню репозитория TortoiseGit > Switch/Checkout...

и выбрать gh-pages.

Таким же образом можно будет вернуться в Master.

Внимание!! переключение бранчей (веток) лучше выполнять, когда все изменения "закоммичены".


...

Полезные ссылки:
Оффициальный сайт Git: https://git-scm.com
Толковая документация по Git [EN]: https://git-scm.com/doc
Git для Windows: https://msysgit.github.io/index.html
Tortoise Git: https://code.google.com/p/tortoisegit/
Книга Pro Git: https://git-scm.com/book/ru/v2
Статья "Удачная модель ветвления для Git": http://habrahabr.ru/post/106912/
https://gist.github.com/cobyism/4730490
https://git-scm.com/docs/gittutorial
http://githowto.com/ru


P.S.: Написано специально для Серёги и Жеки.

Комментариев нет:

Отправить комментарий