Blog Sergeome

На написание данной статьи меня подтолкнуло не совсем полное понимание основ Git со стороны моих друзей/коллег. Хочется обратить ваше внимание на слово "основ" или другими словами - я не буду вдаваться в подробности, так как сам не являюсь экспертом в данной области и признаю своей миссией лишь освятить базовые моменты. Излагая данный материал я сам нуждаюсь в критике, дабы сделать его идеальным и полностью подтвердить правильное осознание его.

Что такое Git? 

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

1. Git не сохраняет ваши файлы, он отслеживает их изменения. 
2. Git отслеживает изменения любых файлов - не только файлов программного кода с определённым рсширением (типа *.java, *.cpp, *.php, *.js и т.д.). Т.е. вы можете отслеживать изменения даже при написании какого-то вордовского документа (диссертации, диплома, курсовой и т.д.), имея возможность вернуться обратно на любой из сохранённых этапов.

Из чего состоит Git? 

Обобщённо говоря - из двух репозиториев (хранилищ) - локального и удалённого.

Локальный репозиторий - это обычная папка на вашем ПК, в которой будут храниться изменяемые файлы. Но чем репозиторий отличается от обычной папки с файлами? А тем, что там хранится ещё одна скрытая папка ".git" - как раз она и "маркирует" папку с изменяемыми файлами как репозиторий. В ".git" находятся настройки репозитория (о них позже) и все изменения, которые вы сохраняли.

Пример структуры локального репозитория

Удалённый репозиторий - это хранилище изменений, только в сети (на удалённом сервере). Таким образом, у вас есть два одинаковых места хранения файлов. Один из них у вас на ПК, другой удалённый. Для расширения кругозора сразу скажу, что удалённый репозиторий это тоже папка, но её структура в корне отличается от "локальной". Туда не передаются ваши файлы. Там хранятся только изменения.

Пример структуры удалённого репозитория

Самыми популярными сервисами удалённых репозиториев могут служить Github или Bitbucket. Если описать разницу в двух словах, то Github наиболее популярный. Там вы сможете найти исходники практически всех open source проектов, фреймворков и т.д. (наверное, даже всех). Зато там нет возможности создать бесплатный приватный репозиторий и сущесвует ограничение на все вместе взятые репозитории в один гигабайт.
С Bitbucket'ом не потратив ни одного зимбабвийского доллара, вы сможете создать приватный репозиторий (причём в неограниченном их количестве), но он менее популярен. Ограничение на один репозиторий - 2 гб. (Данные на момент написания статьи).

Примером использования может служить тот факт, что бесплатные версии своих программ разработчики выкладывают на Github, в то время как их платные варианты - на Bitbucket.

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

Из вышесказанного хотелось бы сделать небольшой, но важный вывод - у локального репозитория может быть несколько удалённых копий.

Пользуясь случаем, хотел бы ответить на один из важных вопросов - Чем отличается Git от Github?

Ответ. Git - это общее название всей системы контроля версий, тем временем как Github - это всего лишь часть этой системы (сервис, который предоставляет удалённые репозитории).

Установка Git.

На официальном портале можно скачать ПО Git'а для разных платформ.

Я бы рекомендовал один из лучших клиентов Git'a для Windows c наиболее наглядным внешним интерфейсом - SourceTree.

Первый репозиторий и первый коммит.

Для начала немного пояснений насчёт того, что такое "коммит". На самом деле в русском языке такого слова не существует и это англицизм, который вошёл в обиход многих разработчиков. От англ. "commit" - это "совершение, внесение вклада". В случае с git - это просто внесение изменений в локальный репозиторий (очень грубо говоря "сохранение"). Теперь как создать первый репозиторий и сделать коммит:  

1. Создаём папку на ПК. 
2. С помощью SourceTree создаём локальный репозиторий.
3. Перемещаем, копируем или создаём контент, изменения которого будем сохранять (для наглядного примера я создал в папке "gittest" обыкновенный текстовый файл "mytestdocument.txt" и в нём написал "helloworld").
   
4. На данном этапе SourceTree скажет нам о том, что нужно проиндесировать измененные файлы. Ставим галочку в "Unstaged files". Как результат наш файл появится в "Staged files" или проиндексированных файлах.
5. Осталось написать комментарий (он всегда обязателен, например "First commit") и сделать коммит нажатием на кнопку "Commit".
   

Шаг 5. Давайте сделаем пуш. Для этого нужно нажать пуш в SourceTree. Как результат появится окно с настройками. Ставим галочку в колонке "Push" и жмём "ОК". У вас должны будут запросить имя и пароль (такие, как на Github), вводим, жмём ок. После всего этого у вас на Github появятся ваши файлы по адресу https://github.com/username/repository-name.git.

Что произошло и как это работает (индексирование, коммит).

На данном этапе я бы хотел рассказать простыми словами о сложном и раскрыть работоспособность базовых моментов git'a изнутри на примере следующего изображения.



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

1. Первая - это рабочая область (Working directory). В ней, мы работаем с файлами (редактируем, изменяем, удаляем или создаём их).
2. Вторая - это область индексации (Staging area). Как только мы хотим сохранить какой-то этап наших изменений, мы добавляем файлы в индекс.
3. Третяя - это область гит-директория (Git directory).

Процесс происходит следующим образом:

1. На начальном этапе мы получаем проект из удалённого репозитория (в данной статье мы этот шаг пропустили, т.к. создавали свой собственный репозиторий). Тем не менее, при создании файла "mytestdocument.txt" я находился в области "Working directory".
2. Как только мы хотим сохранить какой-то этап нашей работы, мы добавляем изменения файлов в индекс (ставим галочку в "Staged files"). В этом случае мы уже находимся в области индексации ("Staging area").
3. "Подтверждаем" сохранение изменений коммитом. После коммита ранее проиндексированные изменения попадают в git-директорию (там они уже остаются навсегда, если не удалять их специальными командами. Но это уже другая история).

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