Добрый день. Продолжаю свой рассказ про онлайн обучение по государственной программе «Цифровые профессии».
Продолжаю публикации непосредственно по программе обучения. Материал беру из лекций, чтобы можно было оценить ценность урока.
Сегодня мы познакомимся с контролем версий. Многие из вас слышали такие слова, как Git и GitHub. Кто-то знает про контроль версий и, возможно, проходил какие-то курсы.
Итак, разберёмся, для чего вообще нам нужен контроль версий как таковой. В качестве примера рассмотрим какую-нибудь задачу. Начнём с немного отдалённого и, возможно, не очень знакомого вам примера.
Допустим, мы написали какую-то программу или подготовили сайт, который работает прекрасно. Выгрузили его в интернет. Люди заходят на этот сайт, пользуются, им всё нравится. Но через некоторое время вы решили, что на сайте не хватает какой-то функциональности. Например, надо поменять меню, добавить страницы, возможно, регистрацию пользователей или что-то ещё. То есть вам понадобилось улучшить сайт и что-то в нём изменить. Первое, что вы сделаете — сохраните рабочую версию сайта. То, что работает хорошо, никто менять на ходу, скорее всего, не будет. Наверняка на вашем компьютере, на сервере или ещё в каком-то месте появится папочка или архив, где будет написано что-то вроде «Версия 1.0» (рабочая версия сайта). После этого вы начнёте создавать новое или видоизменять то, что уже написано. Спустя какое-то время у вас появится ещё одна версия — «Версия 2.0». Вы тоже куда-нибудь её аккуратно положите, чтобы в любой момент к ней вернуться. Если произведённые изменения внезапно всё сломали, вы всегда сможете достать из своего архива старую версию и вернуться к рабочему состоянию.
Причины осуществления контроля версий
Приведём две основные причины для осуществления контроля версий, которые на бытовом уровне кажутся самыми очевидными:
1. Возможность хранить различные версии проекта.
2. Возможность возвращаться к этим версиям.
Соответственно, когда на компьютере мы храним версию нашего прекрасно работающего сайта, это первый пункт. А когда используем папку с сохранёнными материалами как рабочую, это считается возможностью возвращаться к различным версиям. Если таких версий много, то и папок на компьютере также будет много.
Разберём более сложный пример. До этого мы рассматривали случаи самостоятельной работы. Но что происходит, когда в работе участвует несколько человек? Для примера возьмём вариант с написанием текста, который занимает больше нескольких дней, и где участвует несколько человек. Если можете выполнить работу за один присест, то вы, скорее всего, справитесь и без контроля версий. Но если работа занимает у вас неделю, месяц или несколько месяцев, вопрос с контролем версий будет очень актуален.
Поговорим о том, как строится в таких случаях работа. Для примера возьмём написание какого-либо текста:
● написание курсовой, над которой работаете вы и ваш научный руководитель;
● составление отчёта по работе, где участвуете вы, ваши коллеги и начальник, поручивший это делать;
● издание книги, где вы пишете какой-то текст, а главный редактор, читающий его, утверждает или каким-либо образом влияет на вашу работу.
Можете взять любой пример, наиболее близкий вам. Главное — написать какой-то текст, подключив несколько человек.
Допустим, мы пишем курсовую. Сели, написали что-то, и у нас появился первый черновик, занимающий 2–3 страницы. Подготавливаем получившийся вариант и отправляем своему научному руководителю, а он, в свою очередь, его читает. Во время работы над курсовой вместо «Черновик 1» появляется «Черновик 2», то есть её следующая версия. Наш руководитель работает с первой версией — «Черновик 1». Вносит в неё какие-то правки, что-то изменяет, дописывает. Таким образом, у нас появляется несколько веток, по которым наша курсовая готовится. Появилась версия «Черновик 2». У человека, которому мы отправили предыдущую версию, будет «Черновик 1» с комментариями. Но после отправки «Черновик 1» научному руководителю, мы создаём «Черновик 2», внося изменения в свою версию «Черновик 1». Так возникает некоторый конфликт версий. У нас этот текст уже написан по-новому. А другой человек, думая, что в нашем варианте старый текст, переписал его по-своему. В итоге всё это придётся каким-то образом сводить, приводить к какому-то общему итогу. Но, допустим, всё идёт нормально, мы разобрались в этих двух документах, в результате чего появился «Черновик 3». Далее процесс повторяется. Таким образом, итеративно проект пишется, мы делаем свою работу.
На самом деле ситуация начинает усложняться. Появляется множество файлов, каждый из которых называется по-своему. В этом случае надо придумать некоторые правила:
● в одну сторону положить свой черновик, а в другую — утверждённую версию от руководителя или промежуточные версии от руководителя;
● вместо номеров указывать даты;
● организовать другой порядок.
Опять же, если работа длительная, и в ней участвует несколько человек, это очень неудобно.
Появляется много проблем:
● хранение;
● необходимость перекидывать документы друг другу;
● контроль того, что и в каком файле находится;
● забота об актуальности документа;
● контроль того, от кого пришёл документ;
● определение того, в каком документе содержатся собственные правки, а где — правки научного руководителя.
Это очень неудобно и долго. А если работу выполняют уже более двух человек, могут возникнуть серьёзные проблемы. То есть эта система только разрастается, работать так практически невозможно.
Даже если взять Google Docs, который позволяет одновременно нескольким людям работать над одним и тем же файлом, такой вариант в реальных бизнес-задачах применим не во всех случаях. Мы далеко не всегда сможем воспользоваться такими облачными сервисами и одновременно работать над одним и тем же документом. Возьмём самый простой пример. Допустим, вы подготовили какую-то часть документа. К этому документу есть доступ не только у вас, но и у кого-то ещё. И возможно, кто-то внёс некоторые изменения, о которых вы не в курсе. То есть у вас не всегда будет возможность контролировать какие-то изменения в документе. Его часто придётся перечитывать вам или человеку, ответственному за документ. Таким образом, перед нами встают две большие проблемы: путаница в актуальности информации и её безопасность.
Git
Проблема, связанная с тем, о чём сказано выше, возникла давно. Если написание книги или подготовка курсовой — это довольно естественные, но редко встречающуюся примеры, то у программистов проблемы, связанные с совместной работой над проектами, возникли давно. Всё началось в те времена, когда интернет был медленным или он отсутствовал вовсе, память компьютеров стоила дорого, и сохранять полную версию или полную копию какого-то файла считалось роскошью. Программисты решали эту проблему. Эта программа называется Git. Она считается самой популярной, но далеко не единственной и не первой системой контроля версий. Их на самом деле множество. Просто Git сейчас считается самой популярной из используемых систем, хотя разные компании пользуются и другими. Однако смысл и алгоритм их использования во многом похож. И вам, скорее всего, придётся работать с ней в повседневной жизни. Неважно, будете ли вы программистом, тестировщиком, аналитиком или проджектом. Не стоит бояться этой системы. Её задача — помогать вам.
Сначала может показаться, что пользоваться ей довольно сложно. Есть некие действия, к которым вы не привыкли. И гораздо проще сохранить какую-то версию файла, положить её на флешку или сделать с ней что-то ещё. Но на самом деле, если вы привыкнете к программе, то поймёте, что она сильно упрощает жизнь. Стоит её освоить, и ваша работа станет сильно проще. Но вернёмся к Git.
Git написан Линусом Торвальдсом. Это финно-американский программист, который больше известен тем, что написал ядро операционной системы Linux. Вы, скорее всего, о Linux что-то слышали. Естественно, что текущая версия Linux не полностью написана им. Если почитаете о
нём статью на сайте «Википедия», то узнаете, что Линусом Торвальдсом написано буквально 2% от всего Linux. Но на самом деле это уже много. Однако самим идейным вдохновителем создания этой операционной системы и первым программистом, который в ней работал, считается Линус Торвальдс.
Принцип работы Git
Итак, мы рассмотрели две основные особенности, которые возникают, когда нам надо работать над большим проектом. Сначала поговорили о сайте и резервных копиях — версионировании, когда у нас есть рабочая версия, следующая рабочая версия и так далее.
Не надо бояться контроля версий. Git — просто программа, которую вы устанавливаете на свой компьютер. Она решает за вас все вопросы, связанные с версионированием проекта. Ей просто надо немного помогать, а самое сложное она сделает за вас.
Важно понимать, что принцип работы Git несколько отличается от рассмотренного ранее нами. Когда мы копировали файлы целиком, то просто делали полные резервные копии и хранили их в отдельных папках, а кто-то, возможно, в облачном хранилище, на флешке или как-то ещё. Git работает иначе. Предположим, у нас есть одна страница текста. Мы сохранили её как текущую версию. Затем дописали ещё два слова в этот документ и хотим сохранить новую версию, как описывали ранее. Сохраняя копию сайта, мы сохраним две страницы текста. У нас будет первая страница и та же страница, но с двумя дополнительными словами. То есть у нас, по сути, сохранятся две страницы текста. Один файлик и соседний файлик, предыдущая версия и новая версия. Git же сохранит первую страницу и те два дополнительных слова, которые мы написали. То есть сохранит то, что было, а также добавленное. Удалив несколько слов, он сохранит только разницу между файлами. А когда понадобится воспользоваться этим файлом, он самостоятельно и очень быстро его соберёт. Таким образом, Git позволяет сильно экономить память. Предположим, у нас была не одна страница, а тысяча. Мы писали «Войну и мир» и вдруг решили в заключительном слове добавить несколько слов благодарности. В итоге получится документ на тысячу страниц и новая версия, содержащая ту же тысячу страниц и абзац текста. Git сэкономит память (место) примерно в два раза. А если у нас будет не две версии, а, например, сотни версий, Git позволит уже сэкономить в сто раз больше памяти. Он будет с этим работать гораздо эффективнее. В те времена, когда Линус Торвальдс только разрабатывал систему контроля версий, работал над созданием операционной системы Linux, память стоила очень дорого. Если сейчас скопировать файл и пересохранить его несколько раз для нас — простая операция, не требующая никаких усилий, то в те времена каждый лишний байт, тем более килобайт или мегабайт считался чем-то очень тяжёлым. Это бы заняло почти всю свободную память на компьютере. Поэтому Git — очень полезный инструмент, который позволяет легко наладить версионирование любого проекта.
Для работы потребуется
Итак, на этой лекции мы определимся с двумя принципами, с двумя частями системы контроля версий. Нам надо научиться сохранять разные версии и перемещаться между ними. Это похоже на то, как мы сохраняем разные версии файлов, но с использованием программы Git. Для этого потребуется установить на свой компьютер несколько программ —Git и редактор, в котором будем писать. На самом деле можно обойтись и блокнотом, но лучше воспользоваться программой Visual Studio Code. Она бесплатная. Есть версия для Linux, Mac и Windows. Программа очень удобная. Её мы будем использовать как редактор кода и оболочку для системы контроля версий. Ещё она пригодится нам во время самого программирования. Установите эти две программы —Git и Visual Studio Code — на свой компьютер. Чтобы отслеживать изменения, надо где-то наши файлы хранить. Создадим папку на рабочем столе и назовём её, например, git_education. Название можете выбрать любое, для системы контроля версий Git оно никакого значения не имеет.
Настраиваем Visual Studio Code
Итак, чтобы начать работать в этой папке, а программа Visual Studio Code могла взаимодействовать с ней, надо её открыть. В левом верхнем углу есть проводник, кликаем по нему и открываем созданную на рабочем столе папку. Она совершенно пустая. Это обычная папка, какую вы можете создать на своём компьютере. Никакой магии здесь пока не происходит. А чтобы Git начал контролировать то, что происходит в созданной папке, сохранял версии и помогал в работе, надо дать ему команду на отслеживание происходящего. Для этого используется графический интерфейс. Мышкой можно кликать по меню и найти там Git. Соответственно, всё, что мы будем делать на клавиатуре, также выполняется мышкой. Но начинать с этого не рекомендуется. Сразу познакомимся с тем вариантом, которым пользуются опытные программисты.
Терминал
Для этого надо запустить терминал. Чтобы его запустить, перейдём в меню, найдём пункт «Вид» и в выпадающем окошке выберем «Терминал». Если пользуетесь не Mac, а, например, Linux или Windows, пункты меню будут немного отличаться, но вкладку «Терминал» увидите.
Терминал — это окошко, которое появилось справа внизу. В нём будет указана ваша учётная запись, имя компьютера, на котором работаете, и поле для ввода команд. Когда программисты пишут программы, то, скорее всего, делают это в окне с чёрным фоном. Это и есть терминал. Обычные люди привыкли пользоваться мышкой. Если мы работаем на Windows, то всегда можем правой кнопкой мыши нажать на какое-то поле, найти меню и выбрать из него что-то. Клавиатурой почти не пользуемся. Чтобы в программе появился графический интерфейс, то есть все эти кнопочки, по которым можно нажимать, надо приложить много усилий. Нужен дизайнер, который нарисует эти кнопки, и программист, чтобы их аккуратно расположить. Главное — сделать так, чтобы меню было удобным. Это целое отдельное искусство и программы, которые обладают графическим интерфейсом. Они очень дороги как по времени на их разработку, так и в плане усилий программистов. Поэтому программы, которыми пользуются программисты для работ с удалёнными серверами или которые вы самостоятельно станете писать без возможности привлечь дизайнеров, чтобы сделать дизайн программы, будут консольными. То есть вызываться командами, написанными на клавиатуре. Это может немного пугать. Сначала с непривычки людям кажется, что всё это очень сложно. Но когда привыкнете к этому и присмотритесь, вам станет гораздо удобнее пользоваться терминалом, чем искать мышкой пункты меню и запоминать их названия и место. Гораздо удобнее набрать несколько команд в терминале, и программа сделает всё за вас.
Настраиваем Git
Вернёмся к контролю версий. Сейчас пока никакого контроля версий в нашей папке git_education не происходит. Мы можем создавать файлы и сохранять их. Но самой магии, связанной с Git, ещё происходить не будет. Чтобы эта магия случилась, и Git позволял нам контролировать версии и выполнять всё, требуется, надо его инициализировать. Но сначала проверим, что Git настроен.
Для этого в терминале:
● наберём git — это имя программы, которую хотим запустить;
● поставим пробел, то есть отделим имя программы от тех параметров, которые в неё передаём;
● добавим два тире;
● наберём слово version («версия»).
То есть сейчас мы попросим Git вывести свою версию на экран. И если Git установлен и настроен правильно, увидим на экране текущую версию этой программы. Нажимаем на кнопку Enter. Если вы увидели git version, а потом — набор каких-то чисел, значит, Git настроен правильно. А если сделаете опечатку, или Git у вас не настроен, например, вместо git написали cit, появится ошибка. В этом случае терминал пишет, что определённая команда не найдена. Не надо этого пугаться, такое бывает. Вы можете сделать опечатку, и ничего страшного не произойдёт. Посмотрели, что написал терминал, какой команды он не может найти, увидели опечатку и написали всё правильно. Теперь мы хотим, чтобы Git начал отслеживать всё, что будем делать в своей папке.
Повторюсь, для этого нам надо инициализировать Git, запустив специальную команду. Но все команды в Git, как и в программах, работающих с терминалом, мнемонические. То есть их довольно легко запомнить. Особенно если вы хоть немного знаете английский язык.
Мы можем написать git, поставить пробел и попросить программу инициализироваться. Не обязательно писать слово целиком, программисты — люди немного ленивые, и они решили,
что первых четырёх букв будет достаточно.
Если напишем git init, случится именно то, что мы от него хотим. В этой папке Git начнёт творить магию. Нажимаем на Enter и видим некоторые сообщения — в нашей папке Git начинает отслеживать все изменения.
Если посмотрите в проводник, то увидите, что поменялось в этой папке. А если откроете скрытые файлы, заметите, что в папке git_education появилась скрытая папка .git. В ней ничего менять не надо. Это специальная папка для работы Git. Помимо этого, мы можем узнать, что Git думает о нашей папке и её содержимом, а также статус происходящего. Соответственно, для этого пишется тоже очень простая команда,
которую легко запомнить — git status. Git говорит, что мы находимся в ветке master, и никаких коммитов нет. Со словом «коммит» мы сейчас познакомимся. Он говорит: «nothing to commit». Если знаете английский язык, то слово commit уже будет знакомо. Для тех, кто с английским
языком дружит плохо, надо запомнить, что commit — это фиксация.
Git говорит, что у нас пока нет никаких фиксаций, то есть ничего не зафиксировано. Либо можно запомнить как сохранение в играх. То есть пока никаких сохранений у нас нет, и сохранять, то есть фиксировать нечего. В скобках написаны некоторые подсказки по сохранению. Git говорит, что сначала надо создать или скопировать какие-то файлы, а потом, соответственно, вызвать команду git add, чтобы отслеживать эти файлы. Последуем рекомендациям Git, содержащимся в скобках, и создадим новый файл. В нашей папке git_education можно создать новый файл. Отдадим дань программистам и назовём её hello world. Расширение дадим немного необычное — .md, но на самом деле сейчас это не
имеет никакого значения. Можно создать файл .txt, .doc или тот, какой потребуется. Для системы контроля версий никакого значения это не имеет.
Создаём новый файл
Параллельно с контролем версий мы познакомимся с языком разметки Markdown, который обширно используется в интернете. Вам полезно будет уметь им пользоваться. На самом деле он очень простой, поэтому не добавит к процессу обучения новой сложности.
Создаём новый файл — он появляется в нашем окошке. Напишем в нём какой-нибудь текст, например, hello world. Текст может быть любым. Сохраним этот файл, нажав Ctrl+s или Cmd+s, если работаете на Mac. Теперь попросим Git указать текущий статус. Он говорит нам создать файлы. Посмотрим, что случилось с Git, после того как мы создали новые файлы.
Создаём новый файл
Параллельно с контролем версий мы познакомимся с языком разметки Markdown, который
обширно используется в интернете. Вам полезно будет уметь им пользоваться. На самом деле
он очень простой, поэтому не добавит к процессу обучения новой сложности.
Создаём новый файл — он появляется в нашем окошке. Напишем в нём какой-нибудь текст,
например, hello world. Текст может быть любым. Сохраним этот файл, нажав Ctrl+s или Cmd+s,
если работаете на Mac. Теперь попросим Git указать текущий статус. Он говорит нам создать
файлы. Посмотрим, что случилось с Git, после того как мы создал новый файл.
Знакомимся с командами Git
Чтобы снова вызвать команду, которую уже писали, не обязательно набирать её заново. Можно воспользоваться стрелками на клавиатуре. Если нажать стрелочку «вверх», будут открываться те команды, которые создавались до этого. Вы можете переключаться между ними. Поэтому, работая с терминалом, если начинаете к нему привыкать, вам не надо заново писать уже написанные команды. Чтобы вызвать одну из них, используйте стрелочки.
Итак, мы вызвали команду git status. Теперь Git говорит:
● есть не отслеживаемые файлы —Untracked files;
● файлы появились, но он за ними пока не следит.
Если хотите, чтобы Git начал отслеживать изменения в этих файлах и творить свою магию в плане контроля версии, их надо добавить. В терминале для этого есть подсказки, где говорится, что мы можем использовать команду git add (add — «добавить») и указать какие-то файлы, чтобы включить их в фиксацию. Воспользуемся подсказкой Git, наберём git add и укажем файл, который надо добавить. Писать название файла целиком не надо. В терминале есть удобное автодополнение. Мы написали только первые две буквы файла. Если нажать Tab, терминал самостоятельно заполнит то, что надо написать. Появился файл hello world.md, поэтому писать название целиком не надо. Кнопка Tab сильно ускоряет и упрощает работу с терминалом. Нажимаем Enter — никаких сообщений об ошибках нет. Значит, всё прошло успешно. Ещё раз взглянем на статус. Для этого напишем git status. Теперь Git начал отслеживать наши файлы. Он говорит, что некоторые изменения могут быть сохранены, и указывает на созданное. Здесь также есть информация, что у нас появился новый файл, new file, который называется hello world.
То есть всё нормально, магия началась, Git стал отслеживать файлы. Мы можем сохранить те изменения, которые совершили. Если надо сделать некоторые сохранения или зафиксировать текущий статус, вызываем команду git commit и указываем некоторые комментарии, чтобы в
дальнейшем понять, какое было сделано сохранение и для чего. Для этого к команде commit добавим параметр m — сокращение от message («сообщение») — и в кавычках запишем то, что надо запомнить, некий комментарий к сохранению. Их принято писать на английском языке,
Напишем, что мы создали новый файл: «Создали новый файл». Сообщение пишется в кавычках. Далее нажимаем Enter — выскочило сообщение, в котором говорится:
● появился новый коммит с некоторым комментарием, который мы сами написали;
● один файл изменён — в него добавилась одна строка;
● у нас с файлом hello world идёт некоторая работа.
Изменяем файл
Изменим наш файл. Напишем в нём какой-нибудь текст, например, «Начинаем наше знакомство с контролем версий». Наш файл видоизменился. Сохраним то, что добавили. В итоге у нас есть сохранённая версия файла, предыдущая версия и какие-то изменения, которые мы внесли в указанный файл. Посмотрим на текущий статус и вызовем команду git status. Не обязательно писать всё заново, можно просто стрелочками выбрать то, что уже вызывали. Далее мы видим некоторое сообщение от Git:
● мы находимся на ветке мастер;
● появились некоторые изменения, которые пока не сохранены;
● изменён файл hello world.
Мы можем сохранить его новое состояние. Для этого достаточно опять сказать Git, чтобы в текущее сохранение он добавил файл hello world. Причина заключается в том, что файлов может быть несколько, они могут быть изменены, и текущее сохранение требуется сделать только для некоторых файлов. Даже перед тем, как их сохранить отслеживаемые файлы, надо вызвать команду git add. Напишем git add. Далее ещё раз смотрим на статус. Снова строка hello world стала зелёной. То есть у нас есть какой-то изменённый файл, который теперь можем сохранить. Пишем git commit и указываем новое сообщение, например, «Добавили новую строку». Нажимаем Enter— появилось некоторое сохранение.
Создаём журнал изменений
Теперь у нас есть уже два сохранения, с которыми можно работать. Появилась возможность переходить от одной версии файлов к другой, что нам и хочется от системы контроля версий. Но сначала посмотрим, какие версии существуют. Для этого используется специальная команда git log. Log — это просто журнал изменений, каких-то событий, которые у нас хранятся. Набираем git log и видим немного странный вывод, к которому вы скоро привыкнете. Главное, что у нас есть некоторые фиксации (сохранения) — первое сохранение и второе сохранение. К каждому сохранению прикреплены текстовые комментарии, которые мы оставили. И уже можно понять следующее:
● первое сохранение относится к добавлению новой строки;
● второе сохранение относится к созданию нового файла.
Сейчас мы находимся на первом сохранении. Но если хотим перейти к предыдущей версии файла, воспользуемся для этого указанным commit. Это очень непонятное сочетание букв и цифр, по которым можем перейти. Чтобы перейти к какой-то версии, сохранению, надо вызвать команду git checkout. Сейчас это может показаться сложным из-за такого количества терминов. Однако, когда немного поработайте с ними на практике, то быстро привыкнете и легко будете ими пользоваться. После команды «git — пробел — checkout — пробел» укажем, какое сохранение надо загрузить. Можем указать либо название целиком, либо первые четыре символа, что и позволяет Git. Первых четырёх символов достаточно, чтобы понять, какое сохранение надо запустить. Скопируем их и после git checkout укажем именно этот набор символов. Далее нажимаем на Enter — исчезла строка, которую мы писали. То есть версия файла вернулась к сохранённым. Теперь можем вернуться к версии, которая нас интересовала, посмотреть на сохранение и выбрать, например, то, что было выше, затем снова вызвать git checkout и ввести символы. Видим, что случилась магия. Мы перешли к новой версии. У нас опять появилась строка, которую писали.
По сути, сейчас мы прошли весь путь создания файла и фиксации изменений в нём.
Возвращаемся в актуальное состояние
Мы сохраняли разные статусы своего файла и научились между ними переключаться. На самом деле файл создан, и с ним ничего не происходит. У нас есть его актуальная составляющая. Git же показывает предыдущие состояния файла, и путём вызова команды git checkout мы можем переключаться между разными версиями. Однако чтобы дальше работать с этим файлом, нам требуется вернуться в актуальное состояние. Git должен понимать, что мы начинаем что-то менять с той версии, которая была. В дальнейшем поговорим про ветки, где работа будет производиться иначе. Но сейчас, чтобы всё работало и ничего не сломалось, требуется вернуться в актуальное состояние. Для этого надо не просто указать необходимый commit, а что-то иное. Мы сами напишем git checkout master. Master — это название ветки, в которой работаем.
Возврат к предыдущим сохранениям
Теперь посмотрим, что случится, если перейти к предыдущим сохранениям. Вернёмся к первому сохранению, когда мы только создали свой файл. Что случится с названием нашего файла? Через git log вызовем блок изменений и возьмём какой-нибудь самый первый commit. Если у нас многострочный вывод и введено слово and, достаточно нажать кнопку Q (quit), чтобы выйти из этого режима и вернуться к терминалу. Через команду git checkout перейдём к следующему сохранению. Постепенно вы запомните все эти команды. Теперь перейдём к какой-нибудь старой версии нашего файла. Обратите внимание, что файл переименовался, текущий файл удалён. Если открыть файл с исходным состоянием, мы увидим файл уже с неправильным названием. У меня состояние, которое было сохранено, что не удивительно. Git сохраняет все состояния папки, всё, что происходило внутри. Если вы вернулись к моменту, когда файл назывался неправильно, Git вернётся в это состояние. Это на самом деле очень удобно, хотя иногда немного пугает.
Чтобы понять, отличаются ли наши файлы от того, что уже сохранено в commit, вызываем команду git diff. Git diff показывает (difference — «разница») разницу между текущим состоянием файла и тем, что уже сохранено. Набираем git diff — команда ничего не показывает. Это значит, что сохранённый файл полностью идентичен текущему состоянию. Если сохраним изменения, то есть запишем их внутрь файла, нажав Ctrl+S или Cmd+S и вызвав git diff ещё раз, увидим все произведённые изменения.Обратите внимание, Git сравнивает записанные версии файлов. Если что-то меняете, но изменения не записали, для Git файл не изменится. Мы видим, что минусом показываются удалённые строки, а плюсом — добавленные.
Продолжение следует.
Статья написана по материалам лекции: «Введение в контроль версий». Ильнар Шафигуллин, компания «GeekBrains».
