Предыдущий ролик Следующий ролик  

Видео урок: Первый пример: начало работы

Принципы контроля версий

Давайте рассмотрим контроль версий в действии. Сначала мы рассмотрим его на понятийном уровне, а затем начнем с ним работать. Итак, на этой схеме хранилище с вашими файлами изображено в виде​​ большой стрелки вправо. Оно содержит различные версии файлов, добавленные в течение некоторого времени. Итак, в 9 часов утра вы создаете хранилище для вашего нового проекта. Это создает пустую базу данных, в которую можно добавлять файлы для отслеживания. Часто это делается с помощью команды Init. В 10 часов вы создаете myprog.c и добавляете только функцию Main.

Затем вы добавляете ее в хранилище, выполняя внесение изменений (check in). При каждом добавлении или изменении система контроля версий просит вас составить короткое сообщение, содержащее причину изменений. В этом случае мы скажем, что добавляем myprog.c. Позже в 4 часа вы снова редактируете myprog.c, добавляете Func1 и сохраняете ее на жестком диске. Так ваш рабочий набор обновляется и становится отличным от того, который находится в хранилище, поэтому вы вносите изменения снова. Теперь в вашем хранилище находятся две версии файла и два сообщения об изменениях.

Вечером вы, будучи в полном восторге от вашего приложения и от того, как легко использовать контроль версий для отслеживания своих действий, добавляете Func2 и вносите изменения снова в час ночи. Ну что за день! Теперь давайте посмотрим, как это выполняется в Git. Ok, давайте засучИм рукава и действительно начнем работать с системой контроля версий. Мы будем использовать Git, так как это одна из самых популярных систем, используемых в настоящее время разработчиками ПО. Ее легко использовать из командной строки в Windows, Macintosh, и Linux.

Мы установили Git по одной из ссылок для скачивания из файла Links.rtf, который находится в папке Exercise File. Мы не будем разбирать процесс установки здесь, потому что рассмотрим его в главе о Git. Для начала откроем окно командной строки, как у меня, и проверим установку Git. Для этого мы введем git --version и нажмем Enter. Вы должны увидеть что-то вроде этого, git version 1.7 ... и так далее. Информация в этой строке будет меняться в зависимости от того, какую сборку Git вы загрузили и установили.

Убедившись, что Git установлен правильно, мы идем дальше. Сначала мы создадим каталог под названием FSVC1, что значит Fundamentals of Software Version Control, а затем перейдем в этот каталог. Находясь в нем, мы введем git init, чтобы создать хранилище. Git не хранит изменения в одном файле базы данных, который представляет собой хранилище. Он хранит данные о ваших файлах и каталогах и всю их историю в скрытой папке .git.

Чтобы увидеть эту папку в Windows, введите dir /a, и вы увидите папку .git. Мы можем убедиться, что хранилище инициализировано правильно, выполнив git status. Как видите, появляется сообщение о том, что мы находимся в ветке master, что выполнена первоначальная фиксация и больше нечего коммитить. Это значит, что ваш рабочий набор находится в том же состоянии, что и ваше хранилище. Переходим к этапу 2. Мы создадим myprog.c и добавим ее в хранилище.

В Windows мы будем работать в Блокноте, в OS X или Linux используйте ваш любимый редактор текста. Итак, notepad myprog.c. Так как мы создаем файл, нажимаем да, мы хотим создать новый файл, и добавляем функцию Main. Затем сохраняем ее. Теперь наш рабочий набор отличается от состояния хранилища. Каждый раз при добавлении новых файлов вы должны сказать Git, чтобы он начал отслеживать эти файлы. Вы можете сделать это или в два этапа, или в один. Чтобы сделать это в два этапа, мы делаем следующее.

Сначала вводим git add, а затем звездочку, и он добавит все файлы, о которых еще не знает. Затем, если мы снова выполним git status, вы видите, что теперь он знает о новом файле. Чтобы добавить файл в хранилище, мы зафиксируем его, для чего введем git commit -a -m и сообщение Аdd myprog.c.

Сначала вы увидите, что это не работает, потому что git не знает, кто вы. Каждой системе контроля версий нужно знать, кто вы, чтобы она могла ассоциировать все ваши изменения с вами в ваших же интересах. Чаще всего вносить изменения будете вы, но при работе в команде это может быть очень важно. Поэтому мы запустим две команды, которые вы видите здесь: мы введем git config --global user.email, и затем you@example.com, и далее мы введем git config --global user.name, и затем "lynda.com student".

Конечно, здесь вы будете указывать свой адрес электронной почты, ваше имя или идентификатор пользователя, если вы работаете в команде. В таком случае вы договоритесь о том, будете ли вы использовать адреса электронной почты или ваши настоящие имена. В этом курсе мы будем использовать эти строки. Используя систему в частных целях, указывайте свой адрес электронной почты и свое имя. Когда это будет выполнено, мы можем вернуться и попробовать снова сделать коммит. На этот раз коммит сработал. Как видите, git сообщает, что было выполнено изменение одного файла и добавлена одна строка.

Строка Аdd myprog.c - пример сообщений, о которых я упоминал ранее. Вы вводите их для каждой фиксации, чтобы указать, что вы изменили. Это сообщение должно быть коротким и понятным, чтобы в будущем вы или ваши коллеги-разработчики могли понять, почему вы сделали эту фиксацию. Обратите внимание, что в Windows строка всегда должна быть в двойных кавычках. В OS X и Linux она может быть в одинарных кавычках, и мы можем убедиться, что мы все зафиксировали в хранилище, снова запустив git status. Вы увидите, что коммитить нечего. Это значит, что мы добавили все, что должны были.

Теперь, хотя мы прошли только один короткий этап, мы попросим систему контроля версии показать нам историю. Чтобы увидеть подробную историю в Git, введите git log -p. Он говорит, что автор lynda.com student с почтой you@exampleemail.com в такой-то день добавил такой-то файл. Затем он сравнивает и показывает вам разницу между предыдущей версией и текущей.

В данном случае предыдущей версией был новый файл, так что мы видим строки зеленого цвета. В них говорится, что мы добавили функцию Мain. Теперь давайте изменим файл и посмотрим, как на самом деле отслеживаются версии. Откроем myprog.c и добавим Func1. Затем мы сохраним файл и еще раз зафиксируем его с помощью git commit -a -m "Add Func1 ()".

И вы видите, мы сделали одно изменение файла и две вставки. Теперь давайте еще раз посмотрим, как это изменение отслеживается Git, опять выполнив git log -p. Итак, теперь вы можете видеть, что в верхней части экрана есть сообщение Аdd Func1, изменения - пустая строка и строка с Func1, выделенная зеленым. Ниже вы можете увидеть информацию о предыдущей фиксации с сообщением Аdd myprog, а внизу экрана теперь стоит двоеточие с мигающим курсором.

Когда список изменений больше страницы, автоматически включается режим разбиения на страницы, так что вам нужно будет нажимать пробел, пока в окне терминала не отобразится слово End, а затем ввести букву Q, чтобы вернуться к командной строке. Давайте перейдем к последнему этапу. Я еще раз открою myprog.c и добавлю Func2. Опять же, я сохраню файл и выполню коммит.

Если вам интересно, зачем в командной строке дефис a, (дефис m - для сообщения), дефис a делает возможным выполнить коммит в один шаг. По умолчанию в Git вы можете выполнять коммит в два этапа, как мы делали раньше - сначала добавляли файл, затем фиксировали его. Чаще всего, когда я использую Git, я просто делаю все сразу, потому что так я буду знать, что внесу все изменения, и не думать о том, добавил ли я файлы. Когда мы добавляем -a в команду commit, Git автоматически добавляет все новые файлы и выполняет все в одной операции.

Итак, еще раз, мы запускаем git log -p и видим, что мы добавили Func2, затем мы добавили Func1, затем - myprog.c и, наконец, мы добрались до конца. Теперь вы можете заметить, что git log -p выводит слишком много информации. Существует способ получить более короткий вариант истории хранилища, для чего мы делаем следующее. Мы вводим git log, но с другими аргументами. В этом случае мы вводим --oneline, потому что хотим, чтобы каждое изменение отображалось в одну строку, и мы хотим видеть их все, поэтому мы вводим --all.

Сейчас мы видим в обратном хронологическом порядке наши три коммита с сообщениями. Номер, выделенный желтым слева - это ID, который иногда называют идентификатором набора изменений или идентификатором check-in'а. Разные системы контроля версий делают это по-разному, но в них всегда есть ID, который однозначно идентифицирует набор изменений, которые вы внесли. Итак, теперь давайте попросим Git показать нам разницу между нашим начальным изменением и самым последним. Для этого мы будем использовать эти идентификаторы и команду git diff.

Мы введем git diff и укажем здесь самое старое изменение, 6a3e577. У вас эти цифры будут другими, поэтому посмотрите, какие GUID были созданы для вас. Затем мы введем 7555e83. Итак, белым шрифтом выделено, что в исходной версии была только функция Мain, а в последней были добавлены Function1 и Function2.

Позднее мы будем удалять элементы. Вы увидите, что они выделяются красным. Что ж, это около 80% от всего, что вы должны знать, чтобы использовать контроль версий. Оставшиеся 20% мы снова рассмотрим на понятийном уровне, а затем применим на практике.