Всем привет. В этом видео я расскажу про систему управления версиями Git. В разработке часто случаются ситуации, когда например, вам внезапно нужно исправить ошибку в предыдущей версии вашего проекта. И нужно как минимум достать ее исходники, а потом нужно еще и эти изменения внести в текущую версию, или, например, в процессе командной работы программисты вносят изменения в одни и те же файлы, и потом надо как-то объединить эти изменения. Есть вероятность, что кто-то перезапишет чужие правки, или вам надо посмотреть какой код был в этом файле раньше. И во всех этих ситуациях нам помогут системы управления версиями. Их существует много, но самое популярное, это git - распределенная система управления версиями или DVCS, придуманная Линксом Торвелтсом - создателям linux. Вы обязательно должны использовать её для своих проектов даже если вы разрабатываете всё в одиночку. А если вы работаете в команде, то вам без неё не обойтись вообще никак. Так что же такое git. Git, это набор консольных утилит, хотя существуют и графические клиенты, с помощью которых можно контролировать изменения в любых файлов. С git можно откатится на старую версию всего проекта или только отдельных файлов, сравнить версии файлов за разное время, параллельно разрабатывать разные фитчи в проекте и потом объединять эти изменения из разных версий в одну. Git сохраняет всю информацию об изменениях файлов и о своих настройках в папке.git в корне проекта. Эта папка и называется репозиторий. Работать с git можно локально, а можно синхронизировать свой репозиторий с удаленным репозиторием и это позволяет работать над одним проектом нескольким людям совместно. Есть сервисы для хранения репозиториев, например, сайт github.com, gitlab.com, bitbucket.org. А теперь давайте сразу попробуем git на практике. Но сначала его нужно установить. Его можно скачать со страницы git-scm.com/download, а для линукс его можно поставить через пакетный менеджер апт или ю, для Mac ОС через брю. Я думаю, что вы справитесь с установкой самостоятельно, это действительно несложно. Но допустим, что мы уже установили git и если открыв консоль и написав git вы получаете справку git-а, значит все отлично. Теперь для начала работы нужно настроить два параметра. Это имя пользователя и e-mail. Давайте напишем, для этого мы используем команду git config с параметром --global, что мы настраиваем глобальные настройки не для какого-то конкретного репозитория, а вообще на компьютере. И устанавливаем параметр user name, я напишу себя. Вот, и второй параметр, git config -global user email, я напишу свой email. Эти параметры обязательно задавать для того, чтобы у каждого изменения, который вы будете вносить в репозиторий, был правильный адрес. Это позволяет понимать кто какие правки вносил и нужно для работы. Давайте теперь создадим папку проекта, назовем ее git test, перейдем в нее. Теперь мы должны создать в этой папке репозиторий git. Для этого мы используем команду, ну мы можем посмотреть, что сейчас у нас ничего в этой папке нету, она у нас чистая. Мы пишем git init. После этого мы видим, что появилась папка.git, тот самый репозиторий git. Если мы посмотрим команду сейчас git status, то нам сообщит, что мы находимся в ветке master и у нас нет пока вообще никаких изменений, вообще ничего нет в этой папке. Но важно понимать, что мы находимся в ветке master. Ветки, это такой особый механизм, который позволяет делать несколько версий одних и тех же файлов. Сейчас у нас одна ветка по умолчанию. Вот мы создали новый репозиторий, теперь давайте создадим файлы проекта. На самом деле репозиторий можно было создать уже в папки с какими-то файлами и в общем то это без разницы. Но мы создали впустую, теперь мы добавим каких-то файлов, чьи изменения мы хотим отслеживать. Ну допустим создадим файл hello world, hello.py его назoвем и давайте создадим еще какие-то файлы. Ну и давайте создадим ещё какую нибудь директорию., допустим это будет папка logs. Вот мы создали, давайте посмотрим чего мы там создавали, вот у нас появился файлы 11.pyc, 111.pyo, hello.py и logs. А теперь давайте посмотрим, что нам скажет про это всё git status. Смотрите, что мы здесь можем любопытного увидеть. Во-первых, git показывает, что есть несколько неотслеживаемых файлов, но при этом он не показывает вообще папку logs и это правильно. Если в директории нет файлов, то она не участвует в версиаривании, потому что вообще оперирует с файлами. Файлы имеют пути и поэтому могут находиться в директориях, но пустые директории никак не отслеживается. Допустим я хочу еще исключить из отслеживания файлы pyc и pуо. Обычно эти файлы создаются автоматически питоном и содержат скомпилированный код. Они генерируются из файлов руо и поэтому они не нужны мне в репозитории. Для этого мне нужно записать именно исключаемых файлов и папок в специальный файл.gitignore, причем в нем допускаются маски. Такой файл может находиться в любой папке проекта и влияет на нее и все вложенный в нее папки. Мы создадим этот файл в корне. Допустим сделаем echo звёздочка точка ру [со]. Вот такое фактически регулярное выражение больше точка gitignore. Мы создали файл gitignore, теперь посмотрим, что нам скажет git status. Смотрите, файлы pyc и pyo исчезли из сообщения о файлах, которые git видит. Вот файл gitignore соответственно имеет смысл добавлять все папки вроде папок кэшей, папок логов, какие-то папки которые создает ваша среда разработки, в общем весь мусор, который не следует хранить вместе с проектом. А теперь допустим я хочу, чтобы папка logs, которой у нас сейчас не отображается, все таки попала в репозиторий, но вот файлы, которые я буду добавлять внутри этой папки, не попадали. То есть, чтобы сама папка, если кто-то возьмет мой репозитоий, у него появилась, а файлы, которые у меня будут, лого, которые будут создавать моя программа - нет, только структура каталогов. Для этого можно поступить очень просто.Мы создадим внутри папки logs файл gitignore, в котором мы укажем игнорировать всё, кроме самого файла gitignore, и это сразу решить две проблемы. Мы будем игнорировать файлы внутри logs и плюс мы поместим хотя бы какой-то файл внутри папки и она у нас появится в git-е. Ну давайте так и сделаем. Напишем echo '*'' > logs/.gitignore. [inaudible] это проигнорироватьв се, т.е. мы создаем gitignore внутри папки logs и добавим в этот файл еще исключение. Они начинаются с восклицательного знака.!gitignore, то есть; игнорируем все, но не gitignore, добавляем. Нельзя! писать в двойных кавычках, можно за то в одинарных. Баш меня не очень понимает. Теперь давайте посмотрим, что у нас изменилось. И того у нас появилась папка logs. Git видит теперь все нужные файлы, которые я хотел, не видит не нужные, но пока эти файлы не отслеживаемые, о чём git и говорит -untrack files, то есть не под его контролем. Чтобы добавить всё под контроль и подготовить к commit-у, а commit, это есть фиксация текущего состояния файлов, используем команду git add. У git есть понятие изменений, которые будут включены в ближайший commit, так называемое stageing area или область подготовки. Если изменить какой-то файл, то изменения автоматически не попадут в commit, а вот с помощью команды git add мы как раз указываем файлы или целые директории, которые должны попасть в commit. Мы сейчас напишем просто git add. чтобы добавить текущую корневую директорию и все его поддиректории и посмотрим как изменился вывод git status. Заметьте, теперь git напишет, что вот эти изменения попадут в commit и указывает все наши файлы - gitignore, hello.pye и файл gitignore внутри logs. Теперь мы готовы к commit-у. Теперь давайте зафиксируем состояние. То есть сделаем commit. commit, это что-то, вроде стапшота репозиторий на какой-то момент: к нему всегда можно вернуться, посмотреть разницу между двумя commit-ами. Чтобы сделать commit, нужно чтобы были хоть какие то подготовлены изменения. Вот мы и их сделали с помощью команды add и теперь мы можем сделать просто git commit и указать сообщение. Собственно так мы и сделали этот commit. Для commit требуется осмысленное какое-то сообщение, поясняющие какие изменения сделаны. Это нужно для того, чтобы легко ориентироваться в истории commit-ов и понимать о чем каждый из них. Для этого мы указали ключ -м и сообщение. Если бы мы не указали этот ключ, то git открыл текстовый редактор и нам бы все равно пришлось внести это сообщение в нём. Иногда это даже удобнее, особенно когда сообщения длинные. Подведем итоги. Мы узнали, что git лучший помощник разработчика, научились создавать локальные репозитории, указывать, что отслеживать, а что не отслеживать, смотреть текущее состояние репозитрии и commit-ить изменения. А в следующем видео мы научимся смотреть историю изменений, переключаться в ветки, пушать изменения в удаленный репозиторий.
