Научу программировать #1 Системы контроля версий. Git
Глава 1. Системы контроля версий.
1.1 Что это такое?
1.2 Накуа надо, и так все работает
1.3 Как работает внутри
1.4 А как работать
1.5 Работа в команде
1.6 Домашка
1.1 Что такое системы контроля версий?
Системы контроля версий - это программы которые позволяют отслеживать изменения вашего файла, и хранить их. При этом менять информацию в этом файле могут сразу несолько человек. Мы можем перейти в более ранним изменениям или наоборот к более поздним.
Вообще системы контроля версий 2-х типов:
a) Централизованные
б) Распределенные.
Централизованные.
Давайте поговорим о том, в чем разница.
В централизованных системах весь код хранит центральный сервер (бла-бла-бла). Доступ имеют все разработчики ПО. Минусы такого подхода, что у разработчика нет своего репозитория, а если сервак сломается, упадет, сгороит (нужное подчеркнуть). То ни у кого не останется полной рабочей версии ПО. Обмен происходит также, ка ки децентрализовванных.
В настоящее время уже не особо популярны, поэтому подробно останавливаться не будем, дабы не забивать голову. Кому интересно может погуглить инфы много, например: SVN
Децентрализованные
Вот тут уже гораздо интересней - остановимся подробней во второй части. Пока краткое описание, как работает.
как видим у нас есть центральный репозиторий, и при этом у каждого разработчика есть свой, так что если что-то пойдет не так, мы быстро сможем восстановить актуальность состояния ПО.
Коротко рассмотрели, давайте подробней теперь на децентральзованных.
1.2 Накуа надо и как работает
Всем знакома ситуация:
----------------------------
Папки конечно могут называться по разному. Например: "правил дизайн" и т.д.
В папке "Изменения Васи" поменялся файл index.php и т.д.
можно решить таким способом данную проблему:
Вася пишет исправлял файл
...
...
и т.д.
Петя пишет исправлял файл
...
...
и т.д.
Так вот, представьте что у Вас работает над проектом так человек 20-ть, как быстро показать заказчику проект со всеми изменениями?
Правильно подумали, открывает файл и начинаем копировать файлы с изменениями в папку "Рабочая версия". Вам ничего не кажется странным? :) пишите в комменты что думаете о таком подходе.
И у нас вдруг возникает ситуация, что Вася и Петя редактировали один файл.
Что будем делать?
Если честно я хз, как решать подобное, но срок релиза отложился до решения проблемы.
По головке не погладят точно.
Вот тут и приходит на помощь наш репозиторий.
Буду рассматривать git, материалы приведенные мной это книга по git
link to book:
и так поехали.
Я не буду рассматривать установку на свой ПК сервера git
Некоторые моменты, я специально буду опускать, они простые и чаще всего находятся в материале, на которые я привожу ссылки. Они появятся в виде вопросов к концу главы или раздела.
И так мы уже знаем, что наш git - это СКВ.
Как же он устроен и почему на сегодня он лидер в данной области?
Неужели весь код хранится на сервере, каждый файлик.
Это и так и не так.
Во первых все изменения происходят у Вас локально. Т.е. сервер не знает, что вы там наделали. Инфа приходит есму после, того как Вы ее туда отправили.
Локально в момент добавления файла пищется информация о названии файла, что в нем есть (если только добавили), и далее заносится информация о изменениях (я бы назвал ее дельта изменений), кто и когда создал, ветка (позже расскажу) и комментарий.
Получается вот такая картина:
Давайте рассмотрим подробнее что тут отображено:
Version - история изменений (коммитов)
A, B, C - файлы.
Наверное у Вас возникли вопросы, че за **но одни пунктиром, другие нет.
Так в этом и заключается версионность. Сам git не сохраняет полный файл к себе каждый раз, когда вы сохраняете состояние. Он сохраняет только изменения, измененных файлов. Если файл не менялся, то будет просто (условно) сказано (фактически ссылка на файл), файл без изменений.
Получается, что мы можем видеть что конкретно в какой строке поменялось в файле.
Удалилось или добавилось. При этом достаточно компактно.
На сим давайте закончим. Основа задана, далее по линку. А мы поедем дальше.
Самое важное.
Состояния файлов в гит. Это действительно важно, без этого не понять как работает система контроля версий.
и так, есть три состояния:
а) подготовленный - будет включен в репозиторий при commit
б) измененный - изменили файл
в) зафиксированный - зафиксировали, значит отправили с локальный репозиторий (помните где он да?)
Как видно у нас есть файл Petya.txt. Git видит его и сообщает нам о том, что данный файл не добавлен у нас в отслеживание изменений. сейчас у файла нет ни одного из трех состояний.
Их называют не отслеживаемые файлы. Ну само вытекает как бы из этого.
Теперь добавим файл в отслеживание.
(Команды пока я опускаю, мы к ним еще придем.)
Теперь у нас файл принял состояние №1 - подготовленный, т.е. когда мы сохраним данные локально в репозиторий, он будет включен в продукт для изменений. При этом изменения уже начали отслеживаться.
Теперь файл зафиксировали в нашем локальном репозитории. Состояние №3, при отправке на сервер от будет отправлен.
А теперь давайте сделаем состояние №2. Напишем внутри файла строку:
Petya the Best. Как видно на картинке ниже git отметил наш файл как измененный
----------------------------------------------------------------------------------------------
Отдохнули, налили чай. Едем дальше.
И так, что надо сделать, чтобы начать работу.
Далее и на протяжении почти всех постов я буду использовать git для работы, пожалуйста отнеситесь серьезно к этому посту.
Для начала давайте поставим необходимые программы для работы.
Linux: ссылка на мануал по установке
Windows: http://msysgit.github.com/
Для тех кто использует Windows, разработчики git написали:
"Пожалуйста, используйте Git только из командой оболочки, входящей в состав msysGit, потому что так вы сможете запускать сложные команды, приведённые в примерах в настоящей книге. Командная оболочка Windows использует иной синтаксис, из-за чего примеры в ней могут работать некорректно."
После того, как установили приложение приступим уже к практической части.
Когда учили автора статьи использовать технологии командной разработки у нас было 2 дня теории и 4 дня практики, нам дали целый сервер на 20-ть человек и мы делали с ним все что хотели в рамках заданий. Именно поэтому я стараюсь сделать упор именно на практически часть в рамках всего курса. Ну если можно так сказать (:
Фактически у нас есть два способа создать репозиторий. Рассмотрим.
1. Склонировать готовый, (допустим на работе уже давно создано)
2. Создать новый локально.
И так способ 1-й.
Идем на bitbucket.org (github и др.)
регистрируемся, там есть кнопка создать репозиторий, (останавливаться не буду, в сети полно материалов как это сделать).
на ПК создаем каталог в котором будет находится копия нашего ПО, склонированного с сервера. Пишем команду:
git clone https://bitbucket.org/bla-bla-lba (в созданном репозитории на bitbucket уже есть ссылка на проект).
Мы должны в нашей папке увидеть проект, название папки = название проекта.
Жмем создать. Все наш репозиторий на bitbucket создан.
Можем приступать к работе. Внизу на странице у нас две ссылки:
У меня уже есть проект
Я начинаю полностью с нуля
Сейчас мы выберем, я начинаю проект с нуля:
git clone https://nibbler-ws@bitbucket.org/nibbler-ws/testing-repository.git
получаем ссылку на клонирование нашего проекта к себе на ПК.
Я советовал бы всем кто начинает программировать или кто уже умеет, пользоваться консолью.
Теперь открываем консоль и понеслась.
1. Выбираем папку куда будем клонировать наш пустой (пока) репозиторий.
Собственно моя папка куда мы будем производить сие действие.
Оп, наш репозиторий готов. Теперь у нас есть два репозитория, один на нашем сервер, второй на нашем ПК.
И так репозиторий готов, приступим к работе с файлами. Правда для начала давайте пробежимся коротко по GUI приложениям для git:
GitKraken - на мой взгляд просто красивый :) Эта сволоч платная, но красивая.
Есть и free-план
В остальном можно обойтись консолью, так как я работаю в основном на Ubuntu/Mac то клиентов могу назвать еще пару, но можно просто погуглить.
Ладно передохнули, начнем. Создаем файл в нашей папке Petya.txt
touch и прочие мной используемые команды ищите пожалуйста в интернете, они просты, а Вы сразу подучите консоль.
и так мы сделали клон репозитория ранее, перешли в папку, создали файл Petya.txt и попросили git показать статус (назовем это так). В данном случае git говорит нам, что видит наш файл, но он его не отслеживает. Что это значит, а это значит что ничего, что мы там напишем не попадет на наш сервер. Давайте попробуем зафиксировать наши изменения.
Нам сказали, что парень какого? У тебя нихрена не добавлено, давай работай. И показал, что есть файлы которые просто не отслеживает. Снова :) Мы всегда будем их видеть.
Ну давайте скажем следить ему за файлом.
Странно, но нам ничего не сказали. Конечно зачем :) мы уже просто и так добавили файл
Но если сейчас запросить статус увидим, такую картину:
Ага мы получили искомое состояние, файл отслеживается. Отлично. Теперь хочу внести ясность.
То что файл отслеживается, не означает, что все абсолютно все изменения Вы можете вернуть. Вот нифига подобного :) вы можете вернуть только изменения, которые были зафиксированы в состоянии вашего репозитория. Наглядно это выглядит так:
А: ( Строка ХАХАХ ) фиксируем изменения | ( Строка ХАХАХ ) -> ( Строка ХАХАХ2 ) -> ( Строка ХАХАХ123 ) -> ( Строка ХАХАХ Кхе-Кхе ) фиксируем изменения.
В конечном итоге у нас будут в репозитории файл в двух состояний:
А: ( Строка ХАХАХ ) -> ( Строка ХАХАХ Кхе-Кхе ).
Надеюсь это понятно. Едем дальше. Сделаем первый коммит теперь (фиксация изменений).
нам сообщили, что наш файл зафиксирован. 1 файл изменен, строк добавилось 0, удалено 0.
и хэш. Клево правда :)
Посмотрим лог (история фиксаций):
Отлично, давайте разберем, что у нас получилось:
commit - хэш коммита, для чего он буду рассказывать позже.
автор - собственно кто создал коммит.
Дата
И список файлов, которые были изменены.
теперь отправим наши изменения на сервер. Мы помним уже, что наш файл был добавлен и зафиксирован, теперь чтобы все разработчики его увидели нам надо сделать push (или отправить на наш сервер).
Для этого делаем git push.
У меня остался последний блок который я могу добавить :) мать его да у меня статья не влезла полностью первая, надо что-то думать :)
Читая Ваши комментарии и просматривая ссылки наткнулся на такой комментарий от пикабушника.
"Вот ты пишешь, что твои посты в горячем нахер не нужны. B я только на 30 лекции на тебя наткнулся." Пруф по ссылке
Я вот даже не знаю, просить как-то неудобно Вас. А люди мучаются :(
ПЫ.СЫ. вторая часть тоже готова уже, просто все не влезло. Скоро надеюсь смогу публиковать двумя частями. Завтра тогда домашка блин.
