[Студентам] Советы изучающим git
Периодически от студентов приходят вопросы о работе системы контроля версий Git. Частая причина возникновения этих вопросов — непонимание разницы между репозиторием и обычной папкой.
Вот небольшая заметка на эту тему. Давайте разберемся, как работать с папками и репозиториями с точки зрения практики, то есть без строгих определений.
Пункт 1. Про папки и репозитории
Если папка — это то, к чему мы все привыкли как пользователи компьютеров, то репозиторий — это что-то новое, что нужно создать, инициализировать. Сам по себе репозиторий без наших указаний не появляется. Репозиторий в наших задачах — это папка, над которой были произведены некоторые действия, и Git в ней начинает выполнять свои задачи, например:
отслеживать изменения файлов;
хранить информацию о ветках.
Важно! Репозиторий не возникает сам по себе, его нужно создать.
Пункт 2. Как понять, в репозитории мы находимся или в папке
Самый простой способ это сделать — набрать в терминале команду «git status». Если в ответ вы увидите ошибку «fatal: not a git repository (or any of the parent directories): .git», значит, в терминале вы вызываете команду не из репозитория, а из обычной папки. Если вы увидели что-то другое, то вы находитесь в репозитории или внутри одной из папок, которая находится в нем.
Важно! Репозиторий отслеживает изменения во всех вложенных в него папках.
Если вы сделаете репозиторием корневую папку на диске C (не делайте этого!), то весь ваш диск станет репозиторием и Git будет пытаться отслеживать все изменения на этом диске. Создаем репозитории очень аккуратно.
Пункт 3. Как можно создать репозиторий
Чаще всего на начальных этапах рассматривают два способа создания репозитория:
Если мы находимся в папке (!) и хотим сделать из нее репозиторий, то вызываем команду «git init», и эта папка становится репозиторием.
Если мы хотим клонировать репозиторий из GitHub на свой ПК, то мы пользуемся командой «git clone». При этом обратите внимание: не нужно пользоваться командой «git init», команда clone не только скачивает файлы из интернета, но и инициализирует репозиторий в скачанной папке. На самом деле она делает сильно больше, но нам важно, что в скачанной папке у нас уже будет репозиторий и никак дополнительно инициализировать его не надо.
Пункт 4. Внимательно следим за тем, из какой папки вы вызываете команды
Терминал всегда показывает, в какой папке вы сейчас находитесь, но первое время студенты чаще смотрят на то, какая папка открыта в визуальном интерфейсе редактора (например, VSCode), а не на то, что написано в терминале. Обращайте, пожалуйста, внимание на название папки, которая указана в приглашении к вводу команд терминала. До тех пор, пока вы не привыкнете к работе с терминалом, внимательно следите за тем, что вы создаете репозитории только во вновь созданных для урока папках. Не нужно создавать репозитории из рабочего стола или других больших папок.
Пункт 5. Не нужно создавать репозитории внутри другого репозитория
Повторюсь: не нужно создавать репозиторий внутри репозитория. Прежде чем вызывать команды «git init» или «git clone», сначала убедитесь, что вы точно не внутри репозитория. Вызовите «git status» и убедитесь, что вы находитесь в папке, а не в репозитории. Если «git status» выдал ошибку «fatal: not a git repository (or any of the parent directories): .git», значит, вы в этой папке можете воспользоваться одним из способов создания репозитория, рассмотренным выше и на лекциях. Либо «git init», либо «git clone», но не обоими одновременно.
Важно! Иногда студенты сначала вызывают «git init» и потом «git clone». Но тем самым вы нарушаете правило не создавать репозиторий внутри репозитория. Обращайте на это внимание.
Пункт 6. Как репозиторий сделать обычной папкой
Когда вы создаете репозиторий, у вас в папке появляется новая скрытая папка с названием «.git». Это специальная папка, в которой хранится все, что необходимо для работы системы контроля версий. Если вы удалите эту папку, то потеряете всю историю, которую Git успел сохранить, но при этом превратите ваш репозиторий обратно в папку.
Итак, чтобы из репозитория снова сделать папку, достаточно всего лишь удалить скрытую папку «.git». При этом вы потеряете историю, которую собрал Git (все коммиты, ветки и т. п.), но файлы в самой папке останутся в том же виде, в котором они были в момент удаления папки «.git».
Пункт 7. Что делать, если все вокруг стало репозиторием
У студентов, которые неаккуратно вводят команду «git init», такое встречается. Поэтому давайте разберемся, что делать в такой ситуации. Надо проверить, успели ли вы уже совершить такую ошибку. Создайте новую пустую папку, например на рабочем столе, и в терминале вызовите «git status» в этой папке. Если вы увидите «fatal: not a git repository …», то радуемся. Все у вас в порядке.
Если же вы увидели что-то другое, значит, ваша вновь созданная папка является частью какого-то другого репозитория. Важно: мы только что создали новую папку и внутри нее никаких команд кроме «git status» не вызывали, то есть мы не создали сейчас новый репозиторий, но Git при этом не говорит нам, что это «not a git repository». Это может быть только в том случае, если вы эту новую папку создали уже внутри другого репозитория, то есть чуть раньше сделали репозиторием ваш рабочий стол или даже весь ваш диск C. Вылечить такую ситуацию можно следующим образом: нужно найти репозиторий, который вы создали по ошибке, и сделать его обратно папкой (см. предыдущий пункт — нужно удалить папку .git).
Если вы работаете на Windows, включите отображение скрытых файлов и папок, так как папка .git скрытая. Далее начинаем подниматься по иерархии папок вверх и искать в них папки «.git». Например, если вы создали папку по адресу «C:\Users\User\Pictures\ControlCenter\Scan», то сначала проверяете папку Scan, потом проверяете папку ControlCenter, потом Pictures и так далее, пока не найдете скрытую папку .git. Когда нашли и удалили, проводим проверку из начала этого пункта заново.
Введение
Думаю все, кто не знает, что такое Git перестали читать уже после заголовка. Для оставшихся у нас по плану пара статей о внутреннем устройстве git — популярной системы управления версиями. Делаю я это скорее всего потому что мне самому было интересно разобраться как он устроен внутри, а после того, как я проникся всей простотой, мне захотелось поделиться. Хотя я и обещал не останавливаться на очевидных вещах, для начала всё-таки немного надо. Так, чтобы освежить в памяти для кого-то. Начнем с определений:
repository Репозиторий — коллекция коммитов, каждый из которых в свою очередь представляет собой вид рабочего дерева (working tree) на момент совершения коммита. В репозитории так же есть HEAD — символическая ссылка на ветвь (branch) или определенный коммит, над которыми сейчас ведется работа.
В общем обычное использование git выглядит так: после создания репозитория работа происходит в working tree, когда работа доходит до определенной отметки — вы добавляете изменения в индекс (делаете git add), когда индекс содержит всё нужное — создается коммит (git commit). А если вы делаете checkout, то в индекс помещается содержимое того коммита, на который вы его сделали. Если в нем что-то есть, git скажет об этом и предложит что-то сделать. Либо создать коммит, либо похерить. Всё просто. Я даже не буду переводить картинку, это и так очевидно.
Файловая система git
Лично мне первое время было очень интересно, как же происходит вся эта магия. Как человек привыкший к терминам файлов и директорий, знаю устройство файловой системы. Что есть такая абстракция как директории, являющиеся узлами дерева, хранящие некоторую метаинформацию, так же есть i-ноды, являющиеся адресами файлов на жестком диске и листьями этого дерева. На одну i-ноду в UNIX может быть несколько жестких ссылок, то есть один файл может лежать в нескольких директориях. Это просто и всем известно.
К чему я это? Git имеет схожую структуру, за исключением двух ключевых отличий. Первое — файлы представляются в виде blob’ов, то есть аналог i-ноды в git — это имя этого блоба. Забегая вперед, имя — это SHA1 от хеша содержимого и размера файла (опять каламбурчик). В общем имя блоба это почти i-нода за исключением двух вещей: первое — содержимое файла никогда не изменяется (иначе меняется его SHA1, очевидно), второе — файлы с одинаковым размером и содержимым дают нам одинаковый blob. Так что если несколько деревьев ссылается на одинаковые файлы — это как хард-линк. Blob в итоге один. Подумав чуть дальше, читатель может догадаться о трюке с подменой, например blob’ов из разных репозиториев.
Так же blob не хранит никаких метаданных, вся метаинформация о нем хранится в дереве. Таким образом один и тот же blob может входить в одно дерево как файл foo, созданный 20 августа, так же как и в другое дерево как файл bar, созданный 5 лет назад. Помните ведь, что blob не хранит информацию о своем названии? Такое различие обусловлено тем, что файловая система хранит файлы, которые могут изменяться, а blob’ы в git не могут. Такая система имеет свои плюсы и минусы, неизменяемые объекты проще обрабатывать и передавать, но отсюда так же вытекает всем известная нелюбовь git в большим бинарным файлам.
Познакомимся с BLOB
После этого небольшого введения пора перейти к более интересным вещам. Начнем с создания пары файлов, чтобы поиграть с ними.
На данный момент я только создал директорию sample и один файл в ней. Я еще не создал репозиторий, но уже сейчас хочу использовать пару команд git, например, узнать имя захешированного файла (blob’а), который бы получился из нашего.
Можете проверить, запустив эту команду на вашей операционной системе, вы должны получить тот же самый hash id. Даже если вы создадите несколько репозиториев, этот id будет одинаковым везде. То, что я и говорил во введении.
Следующим шагом создадим, наконец, репозиторий и сделаем коммит.
Наш blob должен быть на месте, проверим это. Кстати git нужно всего-лишь первые 6-7 знаков id.
Да, все как мы и ожидали. Мы не смотрели какой коммит или дерево содержит этот blob, мы просто обратились к его содержимому по его id. На самом деле для начала уже хорошо. Ведь весь git строится на blob’ах. Всё, чем он занимается — таскает их по деревьям.
Деревья
Как мы уже выяснили, всё содержимое ваших файлов хранится в blob’ах. Blob’ы не содержат имени файла, не имеют структуры, это просто blob’ы. Git, чтобы отобразить структуру ваших файлов, добавляет эти blob’ы как листья деревьев. Значит где-то должно быть дерево, содержащее только что созданный коммит?
Да, это оно. Это дерево из одного листа — нашего blob’а. Но мы до сих пор не видим дерево, содержащие наш коммит. Для этого нужно проделать еще несколько манипуляций.
Первые две команды показывают нам, что HEAD — это действительно всего лишь ссылка на коммит. Первая декодирует HEAD как реальный id коммита, вторая — отображает его тип. Id этого коммита уже будет отличаться у вас, так как он генерируется от даты и времени создания. Этот id всегда уникален в пределах одного репозитория. И по нему мы снова можем посмотреть дерево blob’ов, которое содержит этот коммит.
Так что мы имеем. У нас есть репозиторий, содержащий 1 коммит, который содержит дерево, которое содержит 1 blob. В этом можно удостовериться, заглянув в .git/objects или использовав еще раз cat-file.
Глубже
Каждый коммит содержит дерево, но как эти деревья создаются? С blob’ами разобрались, но как создать дерево руками? Для начала снесем к чертям всё, что сделали и создадим мир заново.
Помните про индекс? На данный момент всё, что мы сделали — добавили файл в индекс. Нет еще ни деревьев, ни коммитов. Об этом говорит нам лог (он наебнется из-за отсутствия коммитов).
Но самые любопытные из вас, наверное, уже заглянули снова в папочку objects.
Срань господня, что это? Я не коммитил еще ничего, а уже какой-то подозрительный blob с до боли знакомым id появился у нас в stage. Кто не верит, может снова скормить этот id в cat-file или еще как-либо удостовериться. Еще можно удостовериться, что это действительно индекс, посмотрев содержимое .git/index. А мы пока пойдем дальше. Мы там хотели строить деревья. Для записи содержимого индекса в дерево есть специальная команда write-tree.
Этот id’шник нам тоже очень знаком, не правда ли? Это значит, что деревья, содержащие одинаковые blob’ы и поддеревья, имеют одинаковые id. Но мы еще не создали коммит, мы только сделали дерево из содержимого индекса и никуда его не прикрепили. Забегая вперед скажу, что если бросить созданное дерево на произвол судьбы, git отметит его как недоступное (unreachable), то есть мусор. При следующем коммите это дерево будет стерто сборщиком мусора (git gc, можете проверить).
Команда commit-tree как раз и делает то, что нам нужно. Она берет созданное дерево и делает объект-коммит, который его содержит. С помощью опции -p так же можно привязать коммит к родителю, но всё по-порядку. А пока заметим, что id коммита снова другой, ведь он зависит от времени, не забыли? Наша работа еще не закончена, нужно еще зарегистрировать коммит как корень текущего дерева.
Эта хамская команда говорит git о новом коммите совершенно по-наглому. Более безопасный путь это сделать был бы:
Но мы привыкли. После создания главной ветви (master) мы должны еще переместить указатель HEAD на последний коммит в ней. Мы ведь помним про оторванную голову?
Сложно поверить, но мы только что покакали через рот создали новый коммит.
Красота коммитов
Обычно системы контроля версий и особенно маны по ним выставляют ветви (branches) как что-то прекрасное и волшебное, обсуждают их как что-то совершенно отдельное и более высокоуровневое, чем коммиты. В git любая ветвь — это просто коммиты. Много коммитов, связанных между собой отношением сын-родитель. Когда один коммит имеет более одного родителя — это merge, имеет больше одного сына — branch, вот и все. На нашем уровне не существует тегов, бранчей и мержей, есть только коммиты. Ветвь — ничто иное, как ссылка на коммит. Тег не отличается от ветви ничем, кроме того, что имеет описание. Посмотреть дерево коммитов можно командой git branch -v. Конечно, когда ветвей несколько, вывод команды немного более интересный, но у нас пока только один коммит.
На самом деле нам не нужны ссылки вообще. Можно обратиться к любой части дерева просто по id. Например, можно переключиться на другую ветвь командой:
Здесь —hard означает похерить все текущие изменения. Безопасным аналогом этой команды является известный всем git checkout 1ba0b26. Разница еще состоит в том, что без ключа -f изменения не будут похерены.
Понимание системы коммитов — ключ к пониманию устройства git. Когда вы перестанете мыслить ветвями, слияниями и тегами, а в голове будут только коммиты и отношения между ними — вы постигните Дзен. А в следующий раз разберем подробнее как создавать деревья коммитов, то есть ручной branch и merge. Конечно, если у меня будет желание и если хоть кому-то кроме меня это нужно. Пишите комментарии.
Основы GIT ответы на тест. В какой ситуации надо делать git status A чем чаще, тем лучше
Единственный в мире Музей Смайликов
Самая яркая достопримечательность Крыма
Скачать 23.25 Kb.
В какой ситуации надо делать git status?
A) Чем чаще, тем лучше
C) Всегда после команды git pull
D) Только если надо узнать, в каком статусе находится репозиторий, а так эта команда не является обязательной для любой манипуляции
Для чего надо добавлять файлы в .gitignore?
A) Чтобы Git удалял их историю, храня только последнюю версию
B) Чтобы Git при работе с ними переспрашивал «Аге you sure you want to interact with this file?»
C) Чтобы Git не замечал их и любые команды Git не могли их заафектить
D) Файл .gitignore не несет никакой смысловой нагрузки, так что этого не надо делать
Как «спрятать» данные в git?
A) git check —hide
B) git visible —false
Как вывести список удалённых репозиториев с именем и url?
D) git repository
Как добавить новую директорию в Git?
A) Добавить каждый файл из этой директории в Git
B) Добавить хотя бы один файл из этой директории в Git
C) Никак. Git работает только с файлами, т.к. для директорий не бывает изменений и истории
D) Команда: git add -d
Как исправить ошибку «fatal: The current branch mybranch has no upstream branch», возникающую при вводе git push?
A) Никак, придется создавать репозиторий заново
B) Команда: git push -u my_branch
C) Ошибка означает, что fatal в коде, так что надо сначала исправить код проекта
D) Переустановить Git или скачать более новую версию, если она ниже версии 1.2
Как отменить действие команды «git add» на файл?
A) Команда git abort
B) Команда git stash
C) Команда git not-add
D) Команда git reset
Как отменить слияние веток, если произошел конфликт?
A) Команда git stash pop
B) Команда git merge —abort
C) Команда git remove repository
D) Команда git clean
Как перейти из ветки master в ветку dev?
A) git checkout dev
B) git change master dev
C) git branch master dev
Как получить список всех веток?
B) git branch —all
Как посмотреть id коммита?
B) git commit id
Как посмотреть последний коммит у каждой ветки?
A) git branch —last-commit
C) git checkout —last-commit
D) git commit —branch —last-commit
Как привести измененный файл в начальное состояние (до изменения)?
A) Команда git abort path/to/file
B) Команда git checkout path/to/file
C) Команда git pull path/to/file
D) Команда git commit path/to/file
Как применить патч в Git?
A) Команда git apply path/to/file
B) Команда git patch path/to/file
C) Команда git add path/to/file
D) Такого понятия все еще нет
Как проиндексировать несколько файлов одной командой?
A) git add TEXT1.txt, TEXT2.txt, TEXT3.txt
B) git add TEXT1.txt TEXT2.txt TEXT3.txt
C) git add TEXT1.txt ADD TEXT2.txt ADD TEXT3.txt
Как проиндексировать файлы и сделать коммит одной командой?
A) git commit —add -m «Comment»
B) git commit -add -m «Comment»
C) git commit -a -m «Comment»
D) git commit-add -m «Comment»
E) git commit -m «Comment»
Как просмотреть список меток?
A) git show —labels
Как решить конфликт в Git?
A) Руками поправить изменения там, где Git не смог это сделать автоматически и затем собрать все в коммит и запушить
B) Никак, придется создавать репозиторий заново
C) Выполнить команду git commit merge please
D) Удалить файл, для которого Git не знает, как смержить изменения
Как сделать ветку с названием my_branch
A) Команда: git branch my_branch
B) Команда: git create branch my_branch
C) Команда: git commit origin my_branch
D) Команда: git checkout my_branch
Как сделать коммит для ветки my_branch?
A) Надо переключиться на нее и дальше сделать коммит по тем же правилам, что и для ветки master
B) Надо в commit-сообщении прописать название ветки
C) Команда: git fetch origin my_branch
D) Никак, потому что ветки используются не для этого
Как сделать коммит?
A) Всего лишь набрать команду git commit в любой момент времени
B) Сделать изменения в файлах и перечислить их после git commit. Например так: git commit a.file, b.file
C) Сделать изменения, собрать эти изменения командой «git add» или «git commit -а» и указать коммит-сообщение после ключа «-m»
Как скачать ветку their_branch, если она уже есть в удаленном (remote) репозитории, но нет локально?
A) Команда: git clone their_branch
B) Команда: git get origin their_branch
C) Команда: git fetch origin their_branch
D) Команда: git clone origin their_branch
Как создать новую ветку с именем dev?
B) git create dev
C) git branch new dev
D) git create subtree dev
E) git branch dev
Как создать репозиторий git для проекта?
C) git repository —new
Как удалить ветку night?
A) git checkout —delete night
B) git branch —delete night
C) git delete night
D) git branch -d night
Как удалить все untracked файлы?
A) Команда: git clean -f
B) Команда: git delete
C) Команда: git stash
D) Команда: git reset —hard
Как удалить локальную ветку my_branch?
A) Команда: git delete branch my_branch
B) Команда: git branch -D my_branch
C) Команда: git reset my_branch
D) Никак. Git как раз существует для того, чтобы никакие изменения нельзя было удалить
Как узнать, какие изменения мы сделали локально относительно последнего состояния нашего репозитория?
A) Команда git show
B) Команда git diff
C) Команда git izmeneniya
D) Команда git commit
Как узнать, кто автор строчки в файле, используя систему Git?
A) Команда git show —author
B) Команда git commit —author
C) Команда git blame
D) Команда git status
Какова минимальная длина SHA-1 хэша должна быть, чтобы можно было просмотреть информацию о коммите?
Какой командой можно загрузить с GitHub репозиторий на свой компьютер?
Какой текстовый редактор используется по умолчанию в git?
C) Установленный по умолчанию в системе
Какую команду необходимо выполнить, чтобы запустить графический инструмент разрешения конфликтов при merge?
A) git mergemodify
B) git mergemaster
C) git mergecheck
E) git mergetool
Почему бывают конфликты при слиянии веток?
A) Потому что ветки были созданы в разное время
B) Потому что ветки были созданы от разных коммитов
C) Потому что в обеих ветках есть изменения одних и тех же строк
D) Это устаревшая проблема, ее нет с версии Git 1.2
При помощи какой команды можно посмотреть историю всех коммитов с сокращённым SHA-1 хэшем?
A) git log —short-hash
B) git log —abbrev-commit
C) git log —short
D) git log —tiny-commit
Сколько всего веток может быть в репозитории?
A) Сколько угодно
B) Это число настраивается в конфиге
C) Не больше двух
D) Столько же, сколько участников в проекте
Чем директория с репозиторием отличается от любой другой?
A) Ничем, такая же директория
B) Правами доступа — у директории репозитория права доступа только того пользователя, который его «склонил» (git clone)
D) Эта директория прописана в реестре ОС
Чем отличается master и origin master
A) Это просто два разных названия одной ветки
B) master принадлежит локальному репозиторию, a origin master — удаленному
C) Это две разные ветки локального репозитория
D) Ветки origin master не существует
Чем отличаются команды «git push» и «git pull»?
B) Команды «git pull» не существует, а команда «git push» нужна, чтобы выложить изменения в удаленный репозиторий
C) Команды «git push» не существует, а команда «git pull» нужна, чтобы стянуть изменения из удаленного репозитория
D) Команда «git pull» нужна, чтобы стянуть изменения из удаленного репозитория, а команда «git push» нужна, чтобы выложить изменения в удаленный репозиторий
Что делает команда git add?
A) Создает файл с указанным именем и сразу добавляет его в Git
B) Добавляет локальный файл в удаленный репозиторий так, чтобы другие участники проекта могли его видеть
C) Это алиас/синоним команды git commit
D) Начинает отслеживать указанный файл или файлы
Что делает команда git log?
A) Пишет указанный после файл в лог
B) Такой команды нет, есть только команда git look
D) Удаляет файл из репозитория
Что делает команда git show?
A) Показывает изменения, сделанные в указанном коммите
B) Показывает содержимое файла
C) Показывает состояние проекта
D) Показывает время
Что делает команда git stash?
A) Отменяет все изменения
B) Сохраняет все изменения в буфер
C) Удаляет все измененные файлы
D) Такой команды нет
Что делает команда git status?
A) Показывает состояние проекта: кол-во untracked, deleted, new и прочих файлов, количество коммитов, на которое отличается локальная версия репозитория от удаленного и так далее
B) Показывает имя и email нашего пользователя, а также является ли он авторизованным в системе GitHub или нет
C) Показывает место, занимаемое репозиторием на жестком диске и кол-во выделенного под репозиторий месте
D) Такой команды нет, есть только команда git show
Что означает статус файла modified в выводе команды git status?
A) Что файл имеет историю в системе Git и был изменен относительно его последнего состояния
B) Такого статуса нет есть только статусы new и deleted
C) Этот статус виден только командой gitignore и означает что файл перестал отслеживаться системой Git
D) Статус означает что файл добавлен в коммит
Что означает статус файла new в выводе команды git status?
A) Что файл только что был создан и еще не отслеживается системой Git
B) Что файл только начал отслеживаться — Git и пока не имеет истории
C) Что файл удаляли из Git и потом восстановили командой git return
D) Такого статуса нет, есть только статус deleted file
Что означает статус файла untracked в выводе команды git status?
A) Что система Git не отслеживает этот файл
B) Что файл был удален из Git
C) Что файл находится вне репозитория Git
D) Что файл добавлен в .gitignore
Что сделает команда «git branch» без какого либо параметра?
A) Переключится на последнюю используемую ветку
B) Выведет ошибку
C) Выведет список локальных веток
D) Выведет список удаленных (remote) веток
Что сделает команда «git clean -fd»:
A) Будет ошибка, т.к. такой команды нет
B) Будет ошибка, т.к. у команды git clean нет ключа -d
C) Удалит не только untracked файлы, но и папки
D) Удалит не только unrtacked файлы, но и весь репозиторий
Что такое Git Hub?
A) Программа для работы с Git
B) Драйвер для Git
C) Веб-сервис для хостинга IT-проектов и их совместной разработки, основанный на Git
D) UI для работы с локальной версией Git
Что такое ветка в репозитории Git?
A) Это то же самое, что и коммит
B) Это минимум два коммита с одинаковым коммит-сообщением
D) Это механизм изменения конкретного файла
Что такое коммит?
A) Это единица состояния проекта в Git
B) Это результат вывода команды git diff
C) Это обобщающее название одного из статусов файла в выводе git status: untracked, new, deleted или modified
D) Это слово ничего не означает, его ввели только для того, чтобы путать новичков
Что такое репозиторий Git?
A) Любая директория/папка в моей ОС
B) Любая папка, находящаяся внутри Git
C) Репозиторий Git представляет собой каталог файловой системы, в котором находятся файлы конфигурации репозитория, файлы журналов, хранящие операции, выполняемые над репозиторием, индекс, описывающий расположение файлов, и хранилище, содержащее собственно файлы
D) Папка .git/ и все входящие в нее
Что такое слияние двух веток?
A) Когда одну ветку переименовывают в другую
B) Когда все коммиты, сделанные для одной ветки, становятся видимыми во второй ветке
C) Когда выполнили команду git fetch
D) Когда у двух веток скоро появится третья, поменьше, но имеющая признаки обоих родительских веток
Git. Начальное понимание.
На написание данной статьи меня подтолкнуло не совсем полное понимание основ Git со стороны моих друзей/коллег. Хочется обратить ваше внимание на слово «основ» или другими словами — я не буду вдаваться в подробности, так как сам не являюсь экспертом в данной области и признаю своей миссией лишь освятить базовые моменты. Излагая данный материал я сам нуждаюсь в критике, дабы сделать его идеальным и полностью подтвердить правильное осознание его.
Что такое Git?
- Git не сохраняет ваши файлы, он отслеживает их изменения.
- Git отслеживает изменения любых файлов — не только файлов программного кода с определённым рсширением (типа *.java, *.cpp, *.php, *.js и т.д.). Т.е. вы можете отслеживать изменения даже при написании какого-то вордовского документа (диссертации, диплома, курсовой и т.д.), имея возможность вернуться обратно на любой из сохранённых этапов.
Обобщённо говоря — из двух репозиториев (хранилищ) — локального и удалённого.
Локальный репозиторий — это обычная папка на вашем ПК, в которой будут храниться изменяемые файлы. Но чем репозиторий отличается от обычной папки с файлами? А тем, что там хранится ещё одна скрытая папка «.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 — это просто внесение изменений в локальный репозиторий (очень грубо говоря «сохранение»). Теперь как создать первый репозиторий и сделать коммит:
- Создаём папку на ПК.
- С помощью SourceTree создаём локальный репозиторий.
- Перемещаем, копируем или создаём контент, изменения которого будем сохранять (для наглядного примера я создал в папке «gittest» обыкновенный текстовый файл «mytestdocument.txt» и в нём написал «helloworld»).
Пуш на удалённый репозиторий.
Все изменения на локальном компьютере сохранены. Но как же нам сохранить наши труды, если звёзды неудачно сошлись в небе и наш пк разбился/на него вылился кофе и т.д.
Ответ в заголовке — нужно передать наш код на удалённый репозиторий (или по другому — сделать пуш). В данном примере будет использоваться только Github. Пуш на другие удалённые репозитории настраивается схожим образом.
Шаг 1. Регестрируемся на Github.
Шаг 2. Создаём удалённый репозиторий (На примере Github: Вкладка «Repositories» -> «New». Вводим имя репозитория, затем жмём «Create repository»). Удалённый репозиторий уже готов, и нам осталось только передать туда данные.
Шаг 3. Открываем SourceTree. Там выделяем наш репозиторий и нажимаем «Settings». Появилось окно со списком удалённых репозиториев. Т.к. у нас их нет, оно пустое. Жмём «Add».
- Напротив первого поля «Remote name» ставим галочку «Default remote».
- Во втором поле URL/Path вставляем URL из Github вида https://github.com/username/repository-name.git (у меня это был https://github.com/sergeome/test.git)
- Автоматически в DropDown’е должен появиться «Github» и в Host’e https://github.com
- В поле «Username» вводим ваш никнейм (у меня это «sergeome»).
- Жмём «Ок» и затем снова «Ок».
Шаг 5. Давайте сделаем пуш. Для этого нужно нажать пуш в SourceTree. Как результат появится окно с настройками. Ставим галочку в колонке «Push» и жмём «ОК». У вас должны будут запросить имя и пароль (такие, как на Github), вводим, жмём ок. После всего этого у вас на Github появятся ваши файлы по адресу https://github.com/username/repository-name.git.
Что произошло и как это работает (индексирование, коммит).
На данном этапе я бы хотел рассказать простыми словами о сложном и раскрыть работоспособность базовых моментов git’a изнутри на примере следующего изображения.
Если абстрагироваться от удалённого репозитория и обратить внимание только на локальный, то можно убедиться, что он состоит из трёх областей:
1. Первая — это рабочая область (Working directory). В ней, мы работаем с файлами (редактируем, изменяем, удаляем или создаём их).
2. Вторая — это область индексации (Staging area). Как только мы хотим сохранить какой-то этап наших изменений, мы добавляем файлы в индекс.
3. Третяя — это область гит-директория (Git directory).
Процесс происходит следующим образом:
- На начальном этапе мы получаем проект из удалённого репозитория (в данной статье мы этот шаг пропустили, т.к. создавали свой собственный репозиторий). Тем не менее, при создании файла «mytestdocument.txt» я находился в области «Working directory».
- Как только мы хотим сохранить какой-то этап нашей работы, мы добавляем изменения файлов в индекс (ставим галочку в «Staged files»). В этом случае мы уже находимся в области индексации («Staging area»).
- «Подтверждаем» сохранение изменений коммитом. После коммита ранее проиндексированные изменения попадают в git-директорию (там они уже остаются навсегда, если не удалять их специальными командами. Но это уже другая история).
На этом всё.
Пожалуйста, пишите свои замечания по поводу данной статьи в комментариях.