Чем директория с репозиторием отличается от любой другой

Мастер, удалённый, локальный репозитории, репозиторий и форк, в чём отличия?

Репозиторий Git — каталог файловой системы, в котором находятся: файлы конфигурации, файлы журналов операций, выполняемых над репозиторием, индекс расположения файлов и хранилище, содержащее сами контролируемые файлы.

Репозиторий — папка, в которой находятся файлы проекта, index.html и т.д., но в отличие от просто папки на пк, эта папка находится на удалённом сервере (Гитхаб) и только поэтому мы не можем назвать ее просто папкой, а придумали для этого новое слово, которого конечно очень не хватало нашей памяти 🙂

Локальный репозиторий — репозиторий, расположенный на локальном компьютере разработчика в каталоге. Именно в нём происходит разработка и фиксация изменений, которые отправляются в удалённый репозиторий.

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

Мастер (Master) — главная или основная ветка репозитория. мастер-репозиторий, главный репозиторий, от него начинаются форки.

Мастер-репозиторий — папка с файлами проекта находящаяся на удалённом сервере (Гитхаб) к которой есть доступ у лица обладающего правами администратора на эту папку, и через которое (лицо), идёт всё взаимодействите с файлами данной папки (пулреквесты, и т.д.), называющаяся словом "мастер" только потому что с файлами из нее нельзя взаимодействовать напрямую, (с целью сохранения достигнутого в проекте прогресса) но можно по согласованию с лицом, которое имеет над этой папкой — власть. (но если открыт публичный доступ то можно сделать форк).

Форк-репозиторий — копия мастер-репозитория находящаяся на сервере Гитхаб.

Форк-репозиторий — скопированная в свой профиль на гитхабе версия мастер-репозитория, с которой можно спокойно работать, не боясь нанести ущерба тому, что уже сделано.

Удалённый репозиторий — репозиторий, находящийся на удалённом сервере. Это общий репозиторий, в который приходят все изменения и из которого забираются все обновления.

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

Git. Начальное понимание.

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

Что такое Git?

1. Git не сохраняет ваши файлы, он отслеживает их изменения.
2. 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 — это просто внесение изменений в локальный репозиторий (очень грубо говоря «сохранение»). Теперь как создать первый репозиторий и сделать коммит:

1. Создаём папку на ПК.
2. С помощью SourceTree создаём локальный репозиторий.
3. Перемещаем, копируем или создаём контент, изменения которого будем сохранять (для наглядного примера я создал в папке «gittest» обыкновенный текстовый файл «mytestdocument.txt» и в нём написал «helloworld»).

Пуш на удалённый репозиторий.

Все изменения на локальном компьютере сохранены. Но как же нам сохранить наши труды, если звёзды неудачно сошлись в небе и наш пк разбился/на него вылился кофе и т.д.
Ответ в заголовке — нужно передать наш код на удалённый репозиторий (или по другому — сделать пуш). В данном примере будет использоваться только Github. Пуш на другие удалённые репозитории настраивается схожим образом.

Шаг 1. Регестрируемся на Github.

Шаг 2. Создаём удалённый репозиторий (На примере Github: Вкладка «Repositories» -> «New». Вводим имя репозитория, затем жмём «Create repository»). Удалённый репозиторий уже готов, и нам осталось только передать туда данные.

Шаг 3. Открываем SourceTree. Там выделяем наш репозиторий и нажимаем «Settings». Появилось окно со списком удалённых репозиториев. Т.к. у нас их нет, оно пустое. Жмём «Add».

1. Напротив первого поля «Remote name» ставим галочку «Default remote».
2. Во втором поле URL/Path вставляем URL из Github вида https://github.com/username/repository-name.git (у меня это был https://github.com/sergeome/test.git)
3. Автоматически в DropDown’е должен появиться «Github» и в Host’e https://github.com
4. В поле «Username» вводим ваш никнейм (у меня это «sergeome»).
5. Жмём «Ок» и затем снова «Ок».

Шаг 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-директорию (там они уже остаются навсегда, если не удалять их специальными командами. Но это уже другая история).

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

Чем директория с репозиторием отличается от любой другой

Периодически от студентов приходят вопросы о работе системы контроля версий 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?

1. Git не сохраняет ваши файлы, он отслеживает их изменения.
2. 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 — это просто внесение изменений в локальный репозиторий (очень грубо говоря «сохранение»). Теперь как создать первый репозиторий и сделать коммит:

1. Создаём папку на ПК.
2. С помощью SourceTree создаём локальный репозиторий.
3. Перемещаем, копируем или создаём контент, изменения которого будем сохранять (для наглядного примера я создал в папке «gittest» обыкновенный текстовый файл «mytestdocument.txt» и в нём написал «helloworld»).

Пуш на удалённый репозиторий.

Все изменения на локальном компьютере сохранены. Но как же нам сохранить наши труды, если звёзды неудачно сошлись в небе и наш пк разбился/на него вылился кофе и т.д.
Ответ в заголовке — нужно передать наш код на удалённый репозиторий (или по другому — сделать пуш). В данном примере будет использоваться только Github. Пуш на другие удалённые репозитории настраивается схожим образом.

Шаг 1. Регестрируемся на Github.

Шаг 2. Создаём удалённый репозиторий (На примере Github: Вкладка «Repositories» -> «New». Вводим имя репозитория, затем жмём «Create repository»). Удалённый репозиторий уже готов, и нам осталось только передать туда данные.

Шаг 3. Открываем SourceTree. Там выделяем наш репозиторий и нажимаем «Settings». Появилось окно со списком удалённых репозиториев. Т.к. у нас их нет, оно пустое. Жмём «Add».

1. Напротив первого поля «Remote name» ставим галочку «Default remote».
2. Во втором поле URL/Path вставляем URL из Github вида https://github.com/username/repository-name.git (у меня это был https://github.com/sergeome/test.git)
3. Автоматически в DropDown’е должен появиться «Github» и в Host’e https://github.com
4. В поле «Username» вводим ваш никнейм (у меня это «sergeome»).
5. Жмём «Ок» и затем снова «Ок».

Шаг 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-директорию (там они уже остаются навсегда, если не удалять их специальными командами. Но это уже другая история).

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

Чем директория с репозиторием отличается от любой другой

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

Что такое Git?

1. Git не сохраняет ваши файлы, он отслеживает их изменения.
2. 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 — это просто внесение изменений в локальный репозиторий (очень грубо говоря «сохранение»). Теперь как создать первый репозиторий и сделать коммит:

1. Создаём папку на ПК.
2. С помощью SourceTree создаём локальный репозиторий.
3. Перемещаем, копируем или создаём контент, изменения которого будем сохранять (для наглядного примера я создал в папке «gittest» обыкновенный текстовый файл «mytestdocument.txt» и в нём написал «helloworld»).

Пуш на удалённый репозиторий.

Все изменения на локальном компьютере сохранены. Но как же нам сохранить наши труды, если звёзды неудачно сошлись в небе и наш пк разбился/на него вылился кофе и т.д.
Ответ в заголовке — нужно передать наш код на удалённый репозиторий (или по другому — сделать пуш). В данном примере будет использоваться только Github. Пуш на другие удалённые репозитории настраивается схожим образом.

Шаг 1. Регестрируемся на Github.

Шаг 2. Создаём удалённый репозиторий (На примере Github: Вкладка «Repositories» -> «New». Вводим имя репозитория, затем жмём «Create repository»). Удалённый репозиторий уже готов, и нам осталось только передать туда данные.

Шаг 3. Открываем SourceTree. Там выделяем наш репозиторий и нажимаем «Settings». Появилось окно со списком удалённых репозиториев. Т.к. у нас их нет, оно пустое. Жмём «Add».

1. Напротив первого поля «Remote name» ставим галочку «Default remote».
2. Во втором поле URL/Path вставляем URL из Github вида https://github.com/username/repository-name.git (у меня это был https://github.com/sergeome/test.git)
3. Автоматически в DropDown’е должен появиться «Github» и в Host’e https://github.com
4. В поле «Username» вводим ваш никнейм (у меня это «sergeome»).
5. Жмём «Ок» и затем снова «Ок».

Шаг 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-директорию (там они уже остаются навсегда, если не удалять их специальными командами. Но это уже другая история).

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

Основы 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. Частая причина возникновения этих вопросов — непонимание разницы между репозиторием и обычной папкой.

Чтобы исправить ситуацию, Ильнар Шафигуллин, эксперт по data science и методолог программы «Разработчик», подготовил небольшую заметку на эту тему. Давайте разберемся, как работать с папками и репозиториями с точки зрения практики, то есть без строгих определений.

Пункт 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. Урок 2. Внутренняя реализация.
Индексация. Коммиты.
Команды: init, config, status, add, commit.

1. Основные понятия
2. Настройки пользователя Git
3. Создание репозитория. Команда git init.
4. Состояния файлов в Git репозитории. Команда git status.
5. Внутреннее устройство Git. Объекты.
6. Делаем файлы отслеживаемыми. Команда git add.
7. Делаем первый коммит. Команда git commit.
7.1. Создание коммита. Этап 1. Создание графа.
7.2. Создание коммита. Этап 2. Создание объекта коммита
7.3. Создание коммита. Этап 3. Направить ветку на текущий коммит.
8. Делаем второй коммит

1. Задание. Файловая структура.
2. Задание. Условие.
3. Задание. Решение: Код + Видео.
4. Домашнее задание

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

1. Репозиторий – папка проекта, отслеживаемого Git, содержащая дерево изменений проекта в хронологическом порядке. Все файлы истории хранятся в специальной папке .git/ внутри папки проекта.
2. Индекс – файл, в котором содержатся изменения, подготовленные для добавления в коммит. Вы можете добавлять и убирать файлы из индекса.
3. Коммит – фиксация изменений, внесенных в индекс. Другими словами, коммит – это единица изменений в вашем проекте. Коммит хранит измененные файлы, имя автора коммита и время, в которое был сделан коммит. Кроме того, каждый коммит имеет уникальный идентификатор, который позволяет в любое время к нему откатиться.
4. УказателиHEAD , ORIGHEAD и т. д. – это ссылка на определенный коммит. Ссылка – это некоторая метка, которую использует Git или сам пользователь, чтобы указать на коммит.
5. Ветка – это последовательность коммитов. Технически же, ветка – это ссылка на последний коммит в этой ветке. Преимущество веток в их независимости. Вы можете вносить изменения в файлы на одной ветке, например, пробовать новую функцию, и они никак не скажутся на файлах в другой ветке. Изначально в репозитории одна ветка, но позже мы рассмотрим, как создавать другие.
6. Рабочая копия. Директория .git/ с её содержимым относится к Git. Все остальные файлы называются рабочей копией и принадлежат пользователю

1. git init – создает новый репозиторий
2. git status – отображает список измененных, добавленных и удаленных файлов
3. git add – добавляет указанные файлы в индекс
4. git commit – фиксирует добавленные в индекс изменения

Важно
Мы стараемся делать наши уроки доступными для широкого круга пользователей, независимо от операционной системы, на которой они работают. Поэтому все примеры в данном и последующих уроках мы будем приводить на Git Bash . Git Bash – это оболочка, основанная на Bash и реализующая все его стандартные функции.

Если вы пользователь Linux, у вас уже есть Bash , и код из наших примеров может быть выполнен напрямую в Терминале.

Если же вы пользуетесь Windows, то могли заметить, что вместе с основными компонентами Git поставил к вам на компьютер Git Bash . Вы можете запустить ее, нажав ПКМ по директории, откуда вы хотите ее запустить, и выбрав из меню Git bash here . Также вы можете вызывать Git напрямую из встроенной консоли cmd , если вам так удобнее.

В зависимости от области действия и места хранения в Git cуществуют 3 типа настроек:

1. Системные. Представляют собой настройки на уровне всей системы, то есть они распространяются на всех пользователей. Файл с этими настройками хранится по следующему пути: C:\Program Files\Git\etc\gitconfig для Windows и /etc/gitconfig для пользователей Linux/MacOS.
2. Глобальные. Эти настройки одинаковы для всех репозиториев, созданных под вашим пользователем. Среди них есть, например, имя ветки по умолчанию. Файл с этими параметрами хранятся по следующему адресу: C:/User/<имя пользователя>/.gitconfig в windows, или

Изменить настройки Git можно двумя способами:

1. Отредактировать файл gitconfig (на уровне системы) или .gitconfig (глобально) или .git/config (на уровне репозитория) напрямую, то есть используя текстовый редактор.
2. Воспользоваться утилитой git config . Кроме того, с помощью этой утилиты можно посмотреть значение соответствующего параметра.

Команда git config

—global
Изменение настроек на уровне пользователя. Без указания данного ключа настройки будут изменены только на уровне текущего репозитория.

—system
Изменение настроек на уровне системы (то есть сразу для всех пользователей).

Как было сказано выше, репозиторий должен обязательно содержать папку .git/ с историей этого репозитория. Создать эту папку можно двумя способами:

1. Создать новый репозиторий.
2. Клонировать к себе на компьютер существующий репозиторий.

Команда git init

1. Рабочая директория — Working directory . Это файловая структура, с которой непосредственно работает пользователь в конкретный момент времени. Технически же — это копия определенной версии вашего проекта, которую вы извлекли из базы Git и в которую пытаетесь внести свои изменения.
2. Индекс или Область подготовленных файлов — Index / Staging area . Это область, где хранятся имена файлов и изменения в них, которые должны войти в следующий коммит. Технически индекс — это просто файл.
3. Директория Git — Git Directory . Папка, в которой Git хранит все версии вашего проекта и также свои служебные файлы. Данная папка носит название .git и располагается в корневой директории вашего проекта.

Таким образом, получается, что ваши файлы путешествуют между этими тремя областями. Файлы, с которыми вы напрямую работаете — это Working Directory. Что-то изменили в этих файлах — изменилось состояние Working Directory.

Хотите зафиксировать эти изменения — скажите Git, какие именно из всех изменений, вы хотите сохранить. Для этого вы добавляете изменения в файлах во вторую область — Staging (он же Index). Это некое среднее состояние между Working Directory и Git Directory — изменения уже на пути к фиксации, но еще не сохранены в базе Git.

Если вы уверены, что все изменения, которые вы добавили в Index / Staging, необходимо сохранить в базу Git, то вы делаете коммит, и они в сжатом виде помещаются в Git Directory. Теперь все надежно сохранено в папке .git .

А теперь давайте более подробно разберемся с тем, в каких состояниях могут быть файлы с точки зрения Git. Каждый файл может находится только в одном из двух состояний:

1. Отслеживаемый. Об этих файлах Git знает и отслеживает изменения в них. Отслеживаемые файлы в свою очередь могут находится в следующих состояниях:

1. Неизмененный. То есть с момента последнего коммита в файле не было никаких изменений
2. Измененный. То есть с последнего коммита в файле были произведены какие-то изменения.
3. Подготовленный к коммиту. Это значит, что вы внесли изменения в этот файл и затем проиндексировали их, и эти изменения будут добавлены в следующий коммит.

Приведем наглядную визуализацию состояний и переходов между ними.

Команда git status

# Cмотрим на статус файлов
$ git status

new file: discrete math/hw-3/dm_sem_11_done.pdf
new file: it theory/3/itt_3.pdf
deleted: progrmmings/c/non-evaluated/out.txt

Changes not staged for commit:
(use «git add/rm <file>. » to update what will be committed)
(use «git restore <file>. » to discard changes in working directory)
modified: .gitignore

Всю информацию Git представляет в виде «объектов». Объект – это файл, содержащий определенную информацию о репозитории и его файлах. Все объекты хранятся в директории .git/objects/ . Объекты бывают трех типов:

1. Blob (англ. binary large object ) – большой бинарный объект, другими словами просто бинарный файл. Для каждого файла в репозитории формируется blob-файл , который содержит его имя и сжатое содержимое. Blob-файл формируется, когда мы добавляем файл в индекс.
2. Tree (англ. tree – дерево). Дерево – это такой тип графа. Оно нужно нам, чтобы показывать связи между файлами в репозитории. Деревья формируются для каждой директории репозитория (в том числе для корневой) во время коммита и показывают, какие файлы (или поддиректории) лежат в данной директории. Таким образом, объект дерева состоит из имен 1) blob-объектов для файлов, которые лежат в данной директории, и 2) других деревьев для всех поддиректорий.
3. Объект коммита. Этот объект содержит в себе имя автора коммита, время коммита и объект дерева корневой директории проекта.

1. Сжимает содержимое этого файла и создает blob-объект .
2. Записывает имя этого объекта в файл индекса.

1. Git – это большая картотека объектов.
2. Git хранит все файлы и связи между ними, как объекты в директории .git/objects .
3. Объект – это файл с некоторой информацией о репозитории.
4. Объекты бывают трех типов: Blob , Tree и Commit .
5. Blob-объекты хранят информацию о файлах репозитория и их содержимом.
6. Tree-объекты хранят информацию о расположении этих файлов в репозитории.
7. Индекс же нужен Git, чтобы понимать, какие из файлов мы добавим в последующий коммит, а какие – нет.

Команда git add

# Добавляем файл dijkstra.c в индекс:
$ git add dijkstra.c

# Добавляем все измененные файлы в индекс:
$ git add -A
# или
$ git add —all

Теперь видно, что мы добавили файл alpha.txt в индекс и Git видит его. Но что же все-таки произошло? Работал Git так:

1. Создал новый blob-объект.

1. К типу файла (т.е. blob) через пробел дописывается длина содержимого и нулевой байт. В нашем случае для файла alpha.txt , содержащего a мы получим: blob 1\0 .
2. Затем к полученной строке прибавляется само содержимое файла. То есть blob 1\0a .
3. Затем эта строка отдается хэш-функции SHA-1 , которая и выдает нам 40-символьный результат.

Хэширование нужно затем, чтобы однозначно определить файл его содержимым (если содержимое файлов различно хотя бы одним символом, то хэши будут сильно отличаться друг от друга). А разбиение по поддиректориям нужно затем, чтобы потом было проще найти нужный нам файл среди множества других.

Заметьте, что простое добавление файла в Git приводит к сохранению его содержимого в директории objects . Оно будет храниться там, даже если мы удалим alpha.txt из рабочей копии.

2. После сохранения blob-файла , гит добавляет его имя в индекс.

Как было сказано выше, индекс – это список файлов, за которыми следит Git. Он хранится в .git/index . Каждая строчка состоит из имени файла и его хэша. Вот таким получился индекс репозитория, рассмотренного выше:

Видно, что файл num.txt одновременно находится в двух состояниях: подготовленный к коммиту и измененный . Но как такое возможно? Давайте разбираться.

Помните, мы находили хэш-сумму от содержимого файла? Теперь мы это содержимое поменяли и хэш-сумма стала другой. Git это заметил, и предупредил нас. Если мы сейчас сделаем коммит, то в него попадет файл num.txt со значением 1 , а не 1024 . Чтобы в коммит попали новые изменения, нам нужно заново проиндексировать файл num.txt .

Подведем итог
Мы узнали, что:

1. Чтобы сделать файл отслеживаемым, существует команда git add .
2. Когда мы делаем файл отслеживаемым, происходит следующее:
   2.1. Создается blob-объект для этого файла. Имя blob-объекта – 40-символьный хэш содержимого файла, причем первые две буквы хэша отводятся под имя поддиректории в папке .git/objects , а остальные 38 – под имя самого файла. Такое разделение имени ускоряет поиск blob-файла среди других.
   2.2. Имя этого blob-файла записывается в индекс ( .git/index ). С этого момента GIt считает файл подготовленным к коммиту.
3. Если мы поменяем содержимое файла, нам нужно снова добавить его в индекс командой git add .

Команда git commit

-m <описание>
Добавляет к коммиту комментарий. Создать коммит без описания нельзя, но описание можно добавить другими способами (например, из файла). Описывать коммит надо так, чтобы другому человеку было понятно, какие именно изменения вы внесли в данном коммите.

-c <commit>
Берет описание, и информацию об авторе из переданного коммита, когда создает новый. Открывает редактор, давая возможность отредактировать описание коммита.

-С <commit>
То же, что и -с , но не открывает редактор. Берет описание переданного коммита неизменяемым.

# Создаем первый коммит с комментарием Add math hometask

$ git commit -m «Add math hometask»

[master 0b1f669] Add math hometask
11 files changed, 7 insertions(+), 638 deletions(-)
rewrite .gitignore (99%)
delete mode 100644 discrete math/hw-3/dm3.pdf

Теперь давайте разберемся, что только что произошло и что это за буквы с цифрами 10962e7 в первой строчке вывода.
В целом команда git commit делает три шага:

1. Создает граф (дерево), представляющий содержимое версии проекта, для которой делают коммит.
2. Создает объект коммита.
3. Направляет текущую ветку на новый коммит

Создание коммита. Этап 1. Создание графа.

Разберем все по порядку.

1. Режим доступа это одно из следующих чисел:
   1. 100644 – обычный файл.
   2. 100755 – исполняемый файл.
   3. 120000 – символическая ссылка (напр. HEAD ).
   Режимы доступа в Git сложно назвать гибкими: указанные три режима – единственные доступные для файлов в Git, хотя существуют и другие режимы, используемые для директорий и подмодулей.
2. Тип объекта – это строка, которая может принимать значение blob , если объект – это blob-файл , либо tree , если объект – это дерево.
3. Третье значение – хэш объекта. Это тот самый 40-символьный SHA-1 хэш.
4. Ну и последнее значение – это имя файла, из которого был создан blob-файл и получен хэш.

1. Blob-файлы
2. Tree-файлы , они же деревья.

Первая строчка – это дерево директории data/ , рассмотренное выше, а вторая – файл outer.txt.

При этом само это дерево, включающее директорию data/ и файл outer.txt будет иметь хэш c0d2cc3e13d34e7043d2afddb4af8867cc972741 (спойлер: оно пригодится для объекта коммита).

Визуализируя граф корневой директории test_repository получим следующее:

1. Первым шагом в создании коммита является создание древовидных графов.
2. Древовидный граф — это объект типа tree , который хранится в директории .git/objects/ .
3. Деревья нужны, чтобы отразить взаимное расположение файлов и директорий в репозитории.
4. Дерево создается для каждой директории репозитория, в том числе и для корневой.
5. Каждая строчка файла дерева устроена по следующей схеме: <режим доступа> <тип объекта> <хэш объекта> <имя файла, из которого создан объект> .

Создание коммита. Этап 2. Создание объекта коммита

Первая строчка записи указывает на дерево корня репозитория, то есть тот самый граф ( test_repository ) с хэшем c0d2cc3…

Вторая строчка говорит, кто и когда создал коммит, третья – кто и когда записал коммит в репозиторий. Обычно эти две строчки совпадают, но бывают и ситуации, когда один человек записывает в свой репозиторий коммит другого человека, тогда эти строчки будут различаться. Тот, кто запишет коммит к себе будет значится в поле committer , а тот, кто создал этот коммит – в поле author .

Ну и в последней, четвертой, строчке содержится комментарий коммита. В нашем случае – Initial commit .

1. После создания объектов деревьев для всех директорий репозитория, создается объект коммита.
2. Объект коммита состоит из:
   2.1. Объекта дерева корневой директории репозитория
   2.2. Информации о том, кто и когда создал коммит
   2.3. Кто и когда записал коммит в историю репозитория
   2.4. Комментария коммита
3. Обычно пункты 2.2 и 2.3 совпадают, но не всегда.
4. Имя объекта коммита – его хэш. По этому хэшу можно найти любой коммит. Не обязательно использовать все 40 символов хэша, обычно 6-8 бывает достаточно.

Создание коммита. Этап 3. Направить ветку на текущий коммит.

В заключение нам нужно сообщить указателю-ветке, что у нас есть новый коммит. Делает это Git следующим образом:

1. Для начала, нужно посмотреть, на какой ветке мы сейчас работаем (их может быть несколько). Git идет в файл .git/HEAD и видит следующее: ref: refs/heads/develop . Такая запись говорит нам, что HEAD указывает на ветку develop, т. е. ветка, в которой мы сейчас работаем – develop (неудивительно, ведь она единственная).
   Напомню, что HEAD и develop – это ссылки, используемые Git или пользователем для указания на определенный коммит.
2. Затем Git ищет файл .git/refs/heads/develop , но такого файла не существует, поскольку это был первый коммит в нашем репозитории и до сих пор ветке develop было не на что указывать. Поэтому Git создает файл .git/refs/heads/develop и задает его содержимое – хэш объекта-коммита, который мы получили f98b4a7. .

Детально разобравшись с процессами создания коммита, изучим граф после первого и второго коммита.

Для примера рассмотрим репозиторий со следующей структурой:

То есть, как и в предыдущем примере, но без файла outer.txt . Иначе наши графы будут слишком объемными.

Для начала заметим, что наш индекс снова пуст, поскольку все файлы уже добавлены в коммит, а новых изменений нет:

Здесь все, как и в объекте первого коммита, за исключением второй строчки – она новая. Теперь у коммита есть родитель (предок, предшествующий коммит). Чтобы найти родителя, Git проходит в файл .git/refs/heads/develop и смотрит на хэш коммита, который там записан.

После этого Git меняет содержимое .git/refs/heads/develop на хэш текущего коммита. Графически, наш репозиторий теперь выглядит так:

1. Скачать предложенную ниже древовидную структуру из файлов и папок.
2. На основе этой структуры инициализировать репозиторий Git
3. Посмотреть, в каком состоянии находятся рабочая директория, индекс и папка .git
   
4. Внести изменения в один/несколько файлов, добавить их в индекс и затем закоммитить
5. Посмотреть, как в ответ на эти действия изменяется состояние рабочей директории / индекса / папки .git

1. Опишем файловую структуру, на основе которой будем формировать условие задания. При желании вы можете использовать собственную.
2. Дадим условие задания
3. [ ВИДЕО ] Выполним задание по списку и дадим соответствующие комментарии
4. Дадим условие для домашнего задания

1. Основная страница блога index.html
2. Папка pictures , в которой хранятся изображения ( файлы *.jpg ) сайта

1. Основная страница блога index.html
Представляет собой файл, который содержит HTML код главной страницы сайта. Ниже приведено его содержимое:

1) Создайте репозиторий внутри папки wild_animals . Убедитесь, что внутри папки wild_animals появилась папка .git .

1. Изучите содержимое файла конфигурации Git для текущего репозитория .git/config
2. Настройте имя и email пользователя для текущего репозитория
3. Убедитесь, что файл .git/config изменился соответствующим образом

1. Убедитесь, что отсутствует файл индекса .git/index
2. Убедитесь, что папка с объектами Git пустая .git/objects
3. Убедитесь, что указатель HEAD указывает на ветку main

1. Сделайте файлы папки wild_animals отслеживаемыми
2. Обратите внимание на файл индекса .git/index и папку с объектами .git/objects
3. Сделайте коммит
4. Найдите хэш коммита

1. Исправьте опечатку в файле index.html (опечатка в слове Elephant )
2. Добавьте изменения в индекс
3. Сделайте коммит

1. Добавьте в файл index.html секцию для еще одного животного (например, для кенгуру)
2. Добавьте изменения в индекс
3. Сделайте коммит

ТЕОРИЯ
00:20 План видео
01:00 Понятия: репозиторий, Индекс, Коммит, Ветка, Указатель
03:40 Области проекта Git: Рабочая директория(Working Directory), Индекс (Index) и Каталог Git (Git Directory)
06:00 Перемещение файлов между областями проекта
08:20 Состояния файлов Git: Untracked, Unmodified, Modified, Staged
11:15 Команда git status
11:50 Команда git status и состояния файлов
13:50 Объекты Git: Blob- и Tree-объекты, объект коммита
18:40 Добавление файла в индекс
20:00 Добавление файла в индекс. Команда git add.
20:50 Добавление файла в индекс. Этап 1. Формирование Blob-файла
20:55 Добавление файла в индекс. Этап 2. Добавление файла в Индекс.
24:30 Создание коммита
24:50 Создание коммита. Команда git commit.
26:15 Создание коммита. Этап 1. Создание графа.
26:55 Создание коммита. Этап 2. Формирование объекта коммита
29:45 Создание коммита. Этап 3. Смещение указателя HEAD.

ПРАКТИКА
31:45 Чем будем заниматься
32:05 Файловая структура для репозитория
33:20 Задание 1. Создание репозитория
36:05 Задание 2. Настройка пользователя Git
38:40 Задание 3. Работа с директорией .git
45:15 Задание 4. Создание 1-го коммита
51:10 Задание 5. Создание 2-го коммита
55:00 Задание 6. Создание 3-го коммита
59:55 Контакты