Git add что делает

В чем разница между git add ., add -A, add -u и add *?

Есть разные способы добавить все измененные файлы в индекс репозитория Git. В чем разница и зачем столько способов?

git add . git add * git add -u git add -A git add --all git add --no-all

Отслеживать
Nick Volynkin
задан 25 июн 2015 в 3:38
Nick Volynkin ♦ Nick Volynkin
34k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака
ассоциация: stackoverflow.com/questions/572549/…
– user181100
25 фев 2017 в 16:36

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Давайте обозначим категории файлов, которые вообще можно добавлять. Будем использовать те же обозначения, что и в выводе команды git status -s :

M — (modified) отслеживаемые, изменились с прошлого коммита, еще не добавлены
D — (deleted) отслеживаемые, удалены после прошлого коммита, еще не добавлены
? — (untracked) неотслеживаемые, не запрещены к добавлению
! — (ignored) неотслеживаемые, запрещены к добавлению (например, в .gitignore )

Параметры и аргументы

Первое различие — в том, что . — это путь (аргумент), а всё остальное — параметры. Те и другие не исключают друг друга и возможны их сочетания.

Использование абсолютных :/ и относительных . путей с командой add

Путь . обозначает текущую директорию, т.е. ту, в которой была запущена команда.

Начиная с Git версии 2.0, поведение команды add приведено в соответствие с поведением commit и других комманд. Теперь . обозначает не всю рабочую область (working tree), а текущий путь в этой области.

Таким образом, если вы выполняете команду add не в корневой директории проекта (той, где лежит .git/ ), то будет обработано содержимое только текущей директории.

Чтобы явным образом дать указание Git работать со всей рабочей областью, используйте :/ :

# работает одинаково из любой директории, добавляет всю рабочую область git add :/ # путь относительно корневой директории git add :/path/to/files/ # работает только в текущей директории cd test git add . # эквивалентно этому: git add :/test # путь относительно текущей директории cd test git add ./path # эквивалентно этому: git add :/test/path

Если не указан никакой путь к добавляемым файлам, то большинство команд работает во всей рабочей области, а git add и git add —no-all просто не работают.

Сводная таблица

сводная таблица

О функционале команд подробно

git add . git add '*'

Git версии 2.0+ просматривает текущую папку и добавляет файлы M , D , ? .
Git версии 1.х просматривает всю рабочую область и добавляет файлы M , D .

Если ‘*’ дается в кавычках, то обрабатывать его будет Git и это эквивалентно git add . . Исключение: из-под cmd.exe git add ‘*’ не сработает, используйте git add . или git add * .

git add --no-all :/ git add --ignore-removal :/

Эта команда в Git v. 2.0+ работает как git add . в Git v. 1.x, то есть добавляет измененные и новые файлы M , ? во всей рабочей области. Для этой команды обязательно указывать путь.

git add --no-all . #добавляет измененные и новые файлы в *текущей директории* git add --no-all path1/ path2/ # добавляет измененные и новые файлы в путях *относительно текущей директории*

git add -u git add -update

Git обновляет (update) статус уже отслеживаемых файлов т.е. M , D .

git add -A git add --all git add --no-ignore-removal

Эти варианты эквивалентны и добавляют M , D , ? .

Без точки — из всей рабочей области:

git add -A = git add -A :/ = git add :/ + git add -u

С точкой — только текущий путь:

git add -A . = git add . + git add -u .

 git add *

Этот синтаксис лучше не использовать, и вот почему:

При этой команде shell (или bash или другая командная оболочка) просматривает рабочую область и отдает Git список файлов на добавление. Система сработает таким образом, что будут найдены абсолютно все не-скрытые файлы, находящиеся в заданном корне. Вы можете посмотреть на этот список, выполнив echo * . ( Исключение: из-под cmd.exe git add * работает так же как git add ‘*’ на shell/bash. )

Произойдет следующее (здесь мы видим сразу несколько причин не использовать add * ):

Добавятся не изменившиеся с прошлого коммита файлы. Git спокойно и молча «прожует» этот запрос, не влияющий на индекс.
Будут добавлены в индекс файлы в не-скрытых папках M , ? .
Не будут добавлены файлы в скрытых папках. .M , .?
Не будут добавлены удаленные файлы D .
Если будут захвачены игнорируемые файлы ! , то будет попытка их добавить. Git отменит всю операцию и покажет сообщение об ошибке.

Зачем столько способов

Разнообразие параметров ( -u , -A , —no-all ) нужно для того, чтобы можно было добавлять разные группы файлов. Конкретно —no-all . было добавлено для того, чтобы реализовывать старое поведение add . в версиях 1.х.

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

Тонкости в использовании . и :/ нужны для того, чтобы каждую команду можно было выполнять как на всю рабочую область, так и на конкретную подпапку.

Введение в Git: настройка и основные команды

Как установить и настроить Git в различных ОС, создать новые и клонировать существующие репозитории, а также базовые концепции ведения веток.

Эта инструкция — часть курса «Введение в Git».

Смотреть весь курс

Введение

Git — один из видов систем контроля версий (или СКВ). Такие системы записывают изменения в набор файлов, а позже позволяют вернуться к определенной версии.
Вам может пригодиться СКВ, если вы, например, программист, системный администратор, дизайнер (или в целом работаете с массивом изменяющихся файлов) и хотите сохранить каждую версию проекта. Вы сможете вернуться к любому из сохраненных состояний, просмотреть изменения и увидеть их авторов. Так гораздо проще исправлять возникающие проблемы.

В целом СКВ можно разделить таким образом:

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

Очевидно, что Git — не единственная система контроля версий, однако по многим параметрам самая удобная и популярная на сегодняшний день. Благодаря распределенной структуре репозитории Git хранятся на всех клиентских компьютерах, что защищает от потерь данных и позволяет полноценно управлять версиями проекта оффлайн.

Главная отличительная черта Git состоит в подходе к обработке данных. Каждый раз при сохранении данных проекта (коммите) система фиксирует состояние файла (делает снимок) и создает ссылку на этот снимок. Последующие изменения отражаются через ссылки на более ранние версии файла. Нет необходимости снова сохранять файл целиком. К тому же, основываясь на контрольных hash-суммах, система снимков обеспечивает целостность всей истории изменений. На практике это означает, что невозможно (либо крайне трудно) полностью удалить данные из рабочего каталога и утратить к ним любой доступ. В большинстве случаев данные можно восстановить из ранней версии проекта.

Таким образом, систему контроля версий в Git проще всего представлять как поток снимков (сохраненных состояний проекта).

Принципы работы с Git

У проектных файлов в Git есть 3 базовых состояния

Измененные (modified) — файлы в процессе рабочего редактирования.
Индексированные (staged) — та часть измененных файлов, которая уже подготовлена к фиксации после редактирования.
Зафиксированные (committed) — файлы, уже сохраненные в локальном репозитории.

У Git есть рабочий каталог, где хранятся метаданные и локальная база рабочего проекта. Именно эта часть копируется, когда вы клонируете проект (репозиторий) с сервера.

Чаще всего работа с Git устроена примерно так:

Вы вносите правки в файлы рабочей копии проекта.
Индексируете их, подготавливая к коммиту (здесь Git создает снимки новых правок).
Делаете коммит, и индексированные правки наконец сохраняются в вашем каталоге Git.

Установка Git

Создать свой проект и начать пользоваться Git в нем достаточно просто. Мы будем рассматривать работу в командной строке терминала, потому что там реализован полный набор команд. Вероятно, в будущем вам будет проще воспользоваться встроенными инструментами в крупном приложении (например, в Visual Studio, если вы программист).

Однако командная строка все равно удобна для тонкой настройки и «нестандартных» действий, поэтому полезно представлять себе, как управлять проектом через нее.

Сначала потребуется установить Git на свой компьютер.

Установка в Linux

Для дистрибутивов, похожих на Fedora, RHEL или CentOS, выполните команду dnf:

> sudo dnf install git-all

На Ubuntu и других Debian-подобных систем введите apt:

> sudo apt install git

Более подробные сведения можно получить по ссылке: https://git-scm.com/download/linux.

Установка на Mac

Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:

> git --version

И следовать дальнейшим инструкциям.

Если вы пользуетесь Homebrew, запустите команду:

$ brew install git

Установка в Windows

Новейшая сборка доступна на официальном сайте Git по ссылке: https://git-scm.com/download/win (загрузка запустится автоматически).

Настройка Git

Настроить рабочую среду нужно только один раз — после обновлений параметры не сбросятся. Если понадобится, в любое время можно изменить ваши настройки.

Самый удобный способ изменения конфигурации — встроенная утилита git config. Настройки Git имеют три уровня:

Параметры из файла [path]/etc/gitconfig (системные) могут работать для всех пользователей системы и репозиториев. Они редактируются командой git config —system.
Параметры из файла ~/.gitconfig или ~/.config/git/config (глобальные) применяются к одному пользователю, если запустить команду git config —global.
Локальные параметры из файла config в рабочем каталоге .git/config сохраняют только для выбранного репозитория. Ему соответствует команда git config —local.

Если запускать git config без параметров, будет использоваться локальный уровень, никакие из более глобальных настроек не изменятся.

Всю используемую конфигурацию можно просмотреть так:

> git config --list --show-origin

Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:

> git config --global user.name "Danil Z" > git config --global user.email danilz@danilz.com

Также можно выбрать и текстовый редактор, введя команду git config —global core.editor. Например, чтобы выбрать Emacs, выполните:

> git config --global core.editor emacs

В Windows нужно указывать полный путь к файлу. К примеру, для установки Notepad++ нужно запустить подобную команду:

> git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

Стоит отметить, что на практике текстовый редактор в Git может и не пригодиться, особенно если вы активно используете стороннее ПО — например, в Visual Studio все текстовые заметки для Git можно писать в отдельном окне. Текстовые редакторы в командной строке отличаются своеобразным управлением, которое потребует от вас отдельного изучения.

Общий список текущих настроек просматривается с помощью команды git config —list. Проверить, что записано в любой из доступных настроек, можно командой с ключом git config :

> git config user.email

Выбор ветки по умолчанию

Итак, наконец можно создать репозиторий в выбранном каталоге командой git init. Основная ветка автоматически будет названа master. Изменить это (в нашем случае задав ветку main) можно так:

> git config --global init.defaultBranch main

Работа в репозитории

Как правило, есть два варианта начать работу с репозиторием Git:

Можно выбрать локальный каталог и создать новый репозиторий в нем.

Можно клонировать существующий репозиторий с локального компьютера или сервера. Обычно проекты клонируются именно с сервера.

Если у вас на компьютере уже есть рабочий проект, но еще не назначен контроль версий, то нужно сначала перейти в каталог проекта.

> cd /home/user/SomeConsoleApp

> cd /Users/user/SomeConsoleApp

> cd C:/Users/user/SomeConsoleApp

> git init

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

И, наконец, нужно добавить под контроль версий все существующие файлы командой git add . (точка в конце важна!). Можно добавлять и по одному файлу, с помощью git add .

Заодно создадим начальный коммит командой git commit:

> git add readme.md > git commit -m 'Initial project version'

Команду git add можно гибко настраивать с помощью дополнительных параметров (флагов), которые подробно описаны в официальной документации: https://git-scm.com/docs/git-add. К примеру, команда git add —force добавит даже игнорируемые файлы, а git add —update позволит обновить отслеживаемые файлы.

В этом репозитории вы можете продолжать работать и дальше, со временем обновляя его и отправляя рабочие версии на сервер.

Клонирование существующего репозитория

Когда вы работаете в команде, разрабатываемые проекты часто размещают на сервере. Это один из самых распространенных сценариев. Вам нужно получить копию проекта последней версии на свой компьютер, чтобы далее вносить в него свой вклад.

В качестве примера мы будем рассматривать проект, который создадим на ресурсе https://github.com/ . После регистрации на сайте и подтверждения по e-mail нужно создать новый репозиторий, как показано на скриншотах.

Видно, что можно выбрать тип репозитория:

публичный (public) – доступ открыт для любого пользователя, однако права на редактирование выдает владелец проекта;

приватный/скрытый (private) — проект виден только владельцу, другие участники добавляются вручную.

Для нашего примера создадим приватный репозиторий под названием SomeConsoleApp и будем работать с ним далее.

Самые удобные способы клонирования проекта — через протоколы HTTP и SSH, прочесть обо всех более развёрнуто можно по ссылке: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols.

Для наших целей воспользуемся протоколом https и следующей командой:

> git clone https://github.com/DanZDev2/SomeConsoleApp SomeConsoleApp

На вашем компьютере в каталоге, куда вы перешли в командной строке, должен появиться каталог SomeConsoleApp, внутри него — каталог .git и все скачанные файлы репозитория последней версии.

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

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

Сохранение снимков и просмотр статуса проекта

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

Сразу после клонирования все файлы проекта будут отслеживаемыми. Отредактировав их и привнеся что-то новое, вы индексируете (stage) и фиксируете (commit) правки, и так для каждой версии проекта.

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

Проверить состояние файлов в рабочем каталоге можно командой git status. После клонирования консоль выведет примерно такую информацию:

On branch master Your branch is up to date with ‘origin/master’. nothing to commit, working tree clean

Теперь отредактируем файлы (в этом примере было консольное демо-приложение, созданное с помощью Visual Studio) и сравним статус:

>git status On branch master Your branch is up to date with ‘origin/master’. Untracked files: (use “git add . ” to include in what will be committed) Program.cs SomeConsoleApp.csproj SomeConsoleApp.sln nothing added to commit but untracked files present (use “git add” to track)

Теперь зафиксируем изменения. В коммит войдут только те файлы, которые вы изменили и добавили командой git add. Остальные будут лишь дополнительными файлами в каталоге проекта.

Стандартный способ — команда git commit, которую мы уже видели раньше. Без дополнительных аргументов она откроет встроенный текстовый редактор, поэтому для простоты рекомендуется добавить аргумент -m и вписать комментарий в кавычках:

> git commit -m "Task 2: basic project template added"

Для удаления ненужных файлов из репозитория можно использовать команду git rm . Файл также пропадет из рабочего каталога. Выполнить коммит необходимо и в этом случае; до тех пор структура проекта не изменится.

Файл .gitignore

Как упоминалось ранее, в рабочий каталог могут попадать файлы, которые вам бы не хотелось отправлять на сервер. Это и документы с вашими экспериментами или образцами, и автоматически генерируемые части проекта, актуальные только на вашем компьютере. Git может полностью игнорировать их, если создать в рабочем каталоге файл с названием .gitignore и внести в него все имена ненужных файлов и папок.

Открывать файл можно в любом текстовом редакторе. Обычно удобнее не перечислять абсолютно все имена (которые к тому же всегда известны), а воспользоваться подобными инструкциями:

/bin /obj *.pdb *.exe

Если прописать такое содержимое файла .gitignore, то репозиторий git будет полностью игнорировать папки /bin и /obj, а также любые файлы с расширениями .pdb и .exe, хранящиеся в вашем рабочем каталоге.

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

Управление удаленными репозиториями

Просмотреть список текущих онлайн-репозиториев можно командой git remote. Добавить другие — с помощью команды git remote add , например:

>git remote add myDemo https://github.com/DanZDev2/DemoApp >git remote myDemo origin

Отправка изменений в удаленный репозиторий (Push)

На вашем компьютере есть проект со внесенными изменениями, но вы хотите поделиться новой версией со всей командой.

Команда для отправки изменений на сервер такова: git push . Если ваша ветка называется master, то команда для отправки коммитов станет такой:

> git push origin master

Она сработает, если у вас есть права на запись на том сервере, откуда вы клонировали проект. Также предполагается, что другие участники команды за это время не обновляли репозиторий.

Следует к тому же помнить, что в разработке для промежуточных правок часто используется не главная ветка (master), а одна из параллельных (например, Dev). Работая в команде, этому обязательно нужно уделять пристальное внимание.

Получение изменений из репозитория (Pull)

Самый простой и быстрый способ получить изменения с сервера — выполнить команду git pull, которая извлечет (fetch) данные с сервера и попытается встроить/объединить (merge) их с вашей локальной версией проекта.

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

Создание веток и переключение между ними

Создадим две дополнительные ветки Dev и Test (например, одна может пригодиться для процесса разработки, а другая — для запуска в тестирование). Введем команду git branch дважды с разными аргументами:

>git branch Dev >git branch Test

Ветки созданы, но мы по-прежнему работаем в master. Для переключения на другую нужно выполнить git checkout :

>git checkout Dev Switched to branch ‘Dev’ Your branch is up to date with ‘origin/Dev’.

Внесем некоторые изменения в файл README.md и зафиксируем их, чтобы они отразились в ветке Dev:

>git add . >git commit -m “dev readme changed” [Dev #####] dev readme changed 1 file changed, 2 insertions(+)

Если теперь отправить их на сервер, то можно убедиться в появившемся отличии веток:

Для переключения обратно на ветку master нужно снова ввести команду git checkout master. Она не изменялась, а значит, после редактирования проекта ветки разойдутся. Это нормальная ситуация для проектов в Git. Важно только понимать, для каких целей используется каждая из веток, и не забывать вовремя переключаться между ними.

Слияние веток (merge)

Работа над проектами часто ведется в несколько этапов, им могут соответствовать ветки (в нашем примере Dev → Test → master). Отдельные ветки могут создаваться для срочного исправления багов, быстрого добавления временных функций, для делегирования части работы другому отделу и т. д. Предположим, что нужно применить изменения из ветки Dev, внеся их в master. Перейдем в master и выполним команду git merge :

>git merge Dev Updating #####..##### Fast-forward README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

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

Для разрешения конфликтов есть консольная утилита git mergetool. Однако если файл проекта объемный, а общих частей много, пользоваться ей не слишком удобно. Общая рекомендация для таких случаев — пользоваться сторонними инструментами, как и в случае с текстовым редактором для Git.

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

Дальнейшая работа с проектом из репозитория Git, как правило, повторяется по алгоритму:

pull (забрать изменения с сервера);

внести правки, добавить что-то важное в проекте;
add (добавить изменённые файлы к коммиту);

commit (сохранить состояние проекта с комментариями);

push (отправить изменения на сервер).

merge (при необходимости внедрить изменения из другой ветки проекта).

Заключение

Мы рассмотрели, как устанавливать и настраивать Git в различных ОС, создавать новые и клонировать существующие репозитории, получать и отправлять новые версии проекта, а также ознакомились с базовыми концепциями ведения веток.

Этой информации обычно хватает для повседневных задач, связанных с хранением рабочих проектов.

Настройка рабочей среды

Git — это система контроля версий, важный инструмент для работы программиста. Она не требуется для сборки или запуска программ, однако предоставляет некоторые полезные возможности на этапе их написания: хранение предыдущих версий исходного кода и откат на любую из них; отображение изменений, сделанных между его произвольными версиями; контроль совместимости изменений, сделанных несколькими пользователями. Представьте, что лаборатории удалось достать машину времени и с помощью неё отследить, кто перепаивал конденсатор и спалил плату, а затем одним нажатием кнопки отменить эти действия и спасти сбор данных на важном эксперименте вместо того, чтобы ждать новую плату несколько месяцев. Техника пока не дошла до этого уровня, а в программировании подобные инструменты работают уже не одно десятилетие.

В рамках нашего курса у каждого студента будет свой репозиторий для каждой отдельной задачи, которую он будет решать. Копия каждого репозитория будет доступна в Вашем профиле на GitHub — веб-сервисе для хостинга проектов. Можно будет легко начать решать задачу на компьютере в терминальном классе, а продолжить делать это на домашнем ноутбуке. Для этого надо будет закоммитить (или сохранить) изменения у себя в локальном репозитории в терминальном классе, запушить их (то есть отправить на GitHub в свой удаленный репозиторий) и дома запуллить (подтянуть на локальный компьютер) изменения.

Для работы с репозиторием удобно использовать разные ветки. Если коммиты можно сравнить с путешествием во времени, то ветки — это альтернативные реальности, в каждой из которых репозиторий развивается по своему особому пути. Например, отдельные разработчки могут использовать индивидуальные ветки для независимой работы друг от друга, а когда чья-то работа будет закончена, вмерджить (влить) изменения в общую ветку. В нашем курсе у репозиториев по две ветки: одна рабочая, в которой можно сохранять промежуточные результаты (ветка master), и ветка solution, в которую надо будет влить в решение задачи для проверки преподавателем.

Подробнее о том, как сдавать задания с помощью Git и Github, рассказано в разделе «Как сдавать задания»

Основные команды, которые Вам понадобятся в работе:

git add — добавление измененных файлов в индекс. После того, как все нужные файлы будут добавлены в индекс, можно будет из этих изменений сформировать коммит (= сделать сохранение в историю). Можно применять в нескольких формах: git add file1.txt file2.txt для сохранения file1.txt , file2.txt либо git add . — для сохранения всех изменений

git status — просмотр изменений. Показывает разницу между текущим состоянием репозитория и предыдущим коммитом (сохранением)

git commit — коммит (сохранение изменений в Git) в локальном репозитории. Сохраняются все изменения, которые были добавлены в индекс. Употреблять в форме git commit -m ‘commit message’ . Вместо commit message принято писать лаконичный комментарий на английском языке о том, зачем был сделан этот коммит

git push — отправить изменения из локального репозитория в удаленный репозиторий на GitHub. Используйте команду git push origin master (origin — это название удаленного репозитория, а master — это ветки, в которой вы будете работать)

git pull — подтянуть изменения из удаленного репозитория. Вам понадобится команда git pull origin master

Работа с Git не ограничивается этими командами, но для успешной работы в рамках нашего курса этого должно быть достаточно. Для дальнейшего знакомства с Git можно читать документацию. Можете попробовать интересный интерактивный способ изучения Git — тренажер по Git. Можете изучать все подряд для саморазвития, а рамках нашего курса будет полезно попрактиковаться только в двух разделах: “Основы. Введение” и “Удаленные репозитории. Push & Pull — удаленные репозитории в Git!”

Введение

Настройка рабочей среды

Установка и настройка VS Code

Что такое Git?

Установка Git for Windows

Установка компилятора

Установка CMake

Установка Miniconda3

Установка библиотеки GoogleTest

Как отправлять решение задач

Полезные команды для работы с Git

Работа с Git через терминал — это обязательная часть практики каждого современного фронтенд-специалиста. Однако, для начинающих это может показаться сложным. Чтобы упростить процесс обучения, мы собрали для вас все самые необходимые команды, которые пригодятся в работе с Git на первое время.

Первоначальная настройка Git

Работа с любой программой всегда начинается с её настройки. Git можно настроить один раз и менять что-то только по мере необходимости.

Установка имени пользователя, от которого будут идти коммиты.

Установка адреса электронной почты. Обратите внимание, что адрес должен совпадать с тем, на который зарегистрирован аккаунт в Гитхабе.

Установка текстового редактора, в котором будут открываться файлы для решения конфликтов.

С помощью команды git config —list можно посмотреть список всех установленных настроек.

Клонирование репозитория

Для клонирования репозитория нужно ввести команду git clone и указать его адрес. Репозиторий клонируется в текущую выбранную папку в консоли.

Работа с изменениями

Любая работа с изменениями начинается с получения последней версии удалённого репозитория. Получить последнюю версию можно с помощью команды git pull . Будьте внимательны, вызов этой команды сотрёт все незафиксированные изменения.

После внесения любых изменений в проект можно посмотреть статус файлов с помощью команды git status . Она покажет файлы, в которых были произведены изменения, удалённые и новые, требующие добавления.

Чтобы добавить отслеживание новых файлов, необходимо использовать команду git add для добавления нескольких файлов по имени.

В случае если у вас много файлов для добавления, можно воспользоваться командой git add . , которая добавляет отслеживание для всех новых файлов из текущей директории. А команда git add -A добавляет ещё и удалённые файлы, не только из текущей директории, но и из всего локального репозитория.

Помимо добавления файлов, их также необходимо удалять. Для этого существует команда git rm , которая удаляет файлы по их имени.

После того как добавлены все новые и удалены старые файлы, можно делать фиксацию изменений. Фиксация изменений или коммит, очень важна, так как до выполнения этой команды ваши локальные изменения никуда не запишутся. Чтобы добавить коммит, необходимо ввести команду git commit -m «Комментарий к коммиту» .

Стоит отметить, что необходимо правильно разбивать изменения на коммиты и давать полные комментарии к коммитам. Подробнее на эту тему можно почитать здесь.

Если вы внесли изменения и хотите быстро их отменить, то воспользуйтесь командой git reset , которая отменяет все незафиксированные изменения.

По умолчанию, эта команда удаляет только из индекса. А команда git reset —hard безвозвратно удаляет незафиксированные текущие изменения из локального репозитория и из индекса.

Поскольку все вышеописанные действия производятся в локальной копии репозитория, эту копию необходимо отправить на сервер, чтобы другие участники процесса смогли получить актуальную версию. Для этого есть команда git push , которая отправляет все зафиксированные изменения на удалённый репозиторий.

Работа с ветками

Работая с Git, приходится постоянно создавать и перемещаться по веткам.

Команда git checkout -b branch-name создаст ветку с указанным именем и автоматически переключится на неё.

После создания ветку можно отправить на сервер с помощью команды git push origin branch-name .

Аналогично можно забрать себе на компьютер ветку с удалённого репозитория командой git checkout origin/branch-name -b branch-name .

Чтобы не хранить названия веток в памяти или не искать названия веток, существуют две специальные команды, которые позволяют посмотреть все существующие ветки локального репозитория git branch или все существующие ветки удалённого репозитория git branch -r .

Переключиться на любую локальную ветку можно с помощью команды git checkout branch-name .

Прочее

После работы в репозитории могут оставаться различные ненужные, неотслеживаемые файлы и прочий мусор. Чтобы удалить всё лишнее, воспользуйтесь командой git clean -f -d .

Больше статей

Как склеить коммиты и зачем это нужно

Шпаргалка по Git

Как работать с GitHub в большой команде

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

Читать дальше

5 частых ошибок при работе с Git

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

27 августа 2023

Работа с Git через консоль

Задача: форкнуть репозиторий в GitHub, создать ветку и работать с кодом.

Сразу появляется много вопросов — что такое GitHub, какие для этого нужны команды, зачем, а главное, как всем этим пользоваться? Давайте разберёмся.

Когда мы пишем код, мы постоянно туда что-то добавляем, удаляем, и иногда всё может ломаться. Поэтому перед любыми изменениями стоит сделать копию проекта. Если собирать проекты в папки с именами проект1 , проект1_финал и проект2_доделка , вы быстро запутаетесь и точно что-нибудь потеряете. Поэтому для работы с кодом используют системы контроля версий.

Система контроля версий — программа, которая хранит разные версии одного документа, позволяет переключаться между ними, вносить и отслеживать изменения. Таких систем много и все они работают по принципу компьютерной игры, где вы можете вернуться к месту сохранения, если что-то пошло не так.

Git — самая популярная система контроля версий. С Git можно работать через командную строку (или терминал). В каждой системе своя встроенная программа для работы с командной строкой. В Windows это PowerShell или cmd, а в Linux или macOS — Terminal. Вместо встроенных программ можно использовать любую другую — например, Git Bash в Windows или iTerm2 для macOS.

Как работает терминал: мы вводим команду и получаем ответ компьютера — или всё получилось, или где-то ошибка, или нужно ввести что-то ещё — например, пароль. Поэтому большая часть этой инструкции состоит из команд для терминала. Сначала будет непривычно, но вам понравится.

Но давайте по порядку — установим Git на компьютер.

7 августа 2023

GitHub Desktop: обзор и первая настройка

Самая короткая инструкция о том, как сохранить файлы в GitHub и ничего не сломать. И самое главное — никакой консоли, всё через окошки и с помощью мышки. Для этого используем GitHub Desktop.

Внимание! GitHub Desktop не работает на Windows 7×32, поэтому если у вас эта версия системы, обновитесь до Windows 10 или воспользуйтесь программой GitKraken.

В этой статье идёт рассказ о системах контроля версий. Если вы совсем ничего о них не знаете, прочитайте статьи «Словарь терминов для Git и GitHub» и «Введение в системы контроля версий», чтобы понять терминологию и разобраться, зачем мы вообще это делаем.

7 августа 2023

Как склеить коммиты и зачем это нужно

Когда вы открываете пулреквест и ваш код смотрят и комментируют другие, бывает нужно что-то исправить. Обычно такие изменения мы комментируем сообщением вроде «Увеличил шрифт на 2px » или «Поменял оттенок фона в шапке». Такие маленькие изменения интересны, только пока они в пулреквесте. Ревьювер (человек, который смотрит ваш код), может легко узнать, что и когда вы изменили, а не читать весь diff заново, а вы можете легко откатить коммит, если он не нужен. Но когда приходит время вливать пулреквест, эти маленькие коммиты теряют свою ценность. Поэтому лучше их склеить в один.

14 июня 2023

Основные команды для работы с Git

Работа с Git через терминал — это обязательная часть практики фронтендера. Однако для начинающих разработчиков этот инструмент может показаться сложным. Чтобы вам было проще учиться, мы собрали основные команды для работы с Git.

☝ В некоторых командах мы будем писать URL-адрес удалённого репозитория и название проекта в квадратных скобках, вот так — [ссылка на удалённый репозиторий] . Мы делаем это только для наглядности. Вам квадратные скобки ставить не нужно.

22 февраля 2023

Как бесплатно залить сайт на GitHub Pages

Допустим, вы сделали какой-то проект, например, собрали себе портфолио по шаблону, и теперь хотите выложить его в интернет. Если вы использовали только HTML и CSS, то необязательно платить деньги, чтобы загрузить сайт куда-то. Вы можете бесплатно выложить сайт на сервис GitHub Pages. Всё, что нужно — аккаунт на Гитхабе.

29 ноября 2022

Регистрация на GitHub

Создание нового аккаунта на GitHub состоит всего из 10 шагов — и вся регистрация занимает меньше пяти минут.

�� Обратите внимания, что интерфейс Гитхаба регулярно меняется, так что внешне он может отличаться, когда вы читаете эту статью.

Начало регистрации. Так выглядит главный экран Гитхаба, когда вы не зарегистрированы. Главное, что вам нужно заметить — большое поле для ввода почты и зелёная кнопка. Вводите свой адрес и переходите на следующий шаг.

Ввод почты. На следующем шаге начинается регистрация. Подтвердите свою почту с прошлого шага и нажмите Continue (Продолжить).

Пароль. Придумайте сложный пароль, чтобы его никто не взломал. Например, Гитхаб просит, чтобы в пароле было не меньше 15 символов или 8 символов, но тогда должны быть и латинские буквы, и цифры.

Имя профиля. Теперь выберите имя вашего профиля — оно будет использоваться в интерфейсе, в коммитах и комментариях. То есть именно так вас будет видеть любой пользователь Гитхаба. Для разработчика Гитхаб вместо визитки, так что выбирайте что-нибудь приличное, лучше, если ник будет совпадать с вашими никнеймами на других сайтах.

Если имя недоступно, Гитхаб вам об этом скажет. А если доступно — жмите Continue.

Рассылки. Дальше Гитхаб спросит, хотите ли вы подписаться на рассылку об обновлениях. Впечатайте латинскую У, если хотите, или n, если письма вам не нужны. Готовы спорить, мы знаем, что вы выберете.

Капча, чтобы проверить, что вы не робот. Нам при регистрации пришлось два раза выбрать спиральную галактику — не сильно сложно. А если вы робот — не причиняйте вред человеку своим действием или бездействием.

Подтверждение почты. После капчи вам придёт письмо с кодом на почту. Введите его на следующей странице.

Вот здесь. Главное — не ошибайтесь.

Общая информация о вас и вашей команде. Если вы регистрируете аккаунт для себя, выбирайте Just me. Второй пункт — студент вы или учитель. Выбирайте «Студент», если вы не учитель.

Интересы. Дальше Гитхаб спросит вас об интересах — то есть о том, зачем вы регистрируете аккаунт. Из вариантов:

Совместная разработка и код ревью.

Автоматизация. CI/CD, API и другие админские вещи.

Безопасность. Двухфакторная аутентификация, ревью, сканирование кода и списки зависимостей.

Приложения. Выбирайте, если будете использовать GitHub Mobile, CLI, Desktop.

Управление проектами. Проекты, метки, ишьи, вики и другие управленческие дела.

Управление командами. Организации, приглашения, роли, домены.

Сообщество. Выбирайте, если Гитхаб интересен вам как соцсеть.

Вы можете выбрать несколько пунктов или пропустить и не указывать ничего, для этого пролистайте страницу вниз для кнопки Skip customization.

Выбор тарифа. На выбор бесплатный тариф или платный GitHub Pro. Практика показывает, что для большинства личных проектов хватит бесплатного тарифа. В сентябре 2022 в него входили:

Безлимитное количество репозиториев.

2000 минут CI/CD в месяц.

500 мегабайт места в хранилище пакетов.

Поддержка сообщества.

Выбор тоже можно пропустить, тогда у вас будет бесплатный тариф.

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

28 сентября 2022

Работа с Git в Visual Studio Code

Если вы вёрстаете сайты или пишете код в редакторе Visual Studio Code, то Git за пять минут настраивается прямо внутри редактора. Не нужно запоминать команды для консоли, не нужно тыкать в лишние приложения.

Следуйте инструкции и всё получится.

16 сентября 2022

Markdown за 5 минут

Маркдаун, он же markdown — удобный и быстрый способ разметки текста. Маркдаун используют, если недоступен HTML, а текст нужно сделать читаемым и хотя бы немного размеченным (заголовки, списки, картинки, ссылки).

Главный пример использования маркдауна, с которым мы часто сталкиваемся — файлы readme.md , которые есть в каждом репозитории на Гитхабе. md в имени файла это как раз сокращение от markdown.

Другой частый пример — сообщения в мессенджерах. Можно поставить звёздочки вокруг текста в Телеграме, и текст станет полужирным.

Версии маркдауна отличаются, поэтому перепроверьте, какую вы используете.

5 октября 2021

Шпаргалка по Git. Решение основных проблем

Поговорим о решении проблем с Git.

11 декабря 2020

Похожие публикации:

Aptio setup utility как выйти

Как открыть 2 проекта в visual studio

Как редактировать файл в ворде

Как снять дамп оперативной памяти