Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

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

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

3 <h2>Как работать с Git?</h2>

4 В Git имеется много команд, поэтому разобьём их по теме и причине использования. Но начнём с того, что рассмотрим работу Git на локальной машине, ведь большая часть операций происходит именно там. После этого перейдём к многопользовательскому формату.

5 Вообще, с Git можно работать и через графический интерфейс (например, GitHub Desktop), и через командную строку. Командную строку изучить необходимо хотя бы потому, что она предоставляет больше возможностей, чем некоторые инструменты с интерфейсом.

6 Обычно, команды Git имеют следующий вид:

7 git <команда> <аргументы>В качестве аргумента может быть путь к файлу. Также у команд бывают опции, обозначаемые --<опция> либо -<однобуквенная опция>. Они обеспечивают болеедетальную настройкудействия команды. В нашем материале команды будут представлены в общем виде, а значит всё, что будет в <>, вы можете менять на собственные значения.

8 Кстати, если возникают затруднения с использованием той либо иной команды, рекомендуется открыть руководство посредством git help <команда>. Если просто нужно напоминание, применяйте git <команда> -h либо git <команда> --help (в Git -h и --help имеют одинаковое значение).

9 <h2>Установка Git</h2>

10 Если вы пользуетесь Windows, качайте Git<a>отсюда</a>. Что касается macOS, то здесь Git поставляется как часть инструмента командной строкиXCode. Наличие Git можно проверить, открыв терминал и набрав git --version. Для Linux используйте команду sudo apt install git-all либо sudo dnf install git-all.

11 <h2>Настраиваем конфигурационный файл</h2>

12 Сразу после установки Git нужно настроить имя пользователя и email, ведь они используются для идентификации. Данные настройки будут сохранены в конфигурационном файле.

13 Вы можете отредактировать файл .gitconfig напрямую с помощью редактора или, используя команду git config --global --edit. Чтобы отредактировать отдельные поля, подойдёт git config --global <поле> <значение> - здесь нас интересуют поляuser.emailиuser.name.

14 Кроме того, есть возможность настройки текстового редактора для написания сообщений коммитов - это полеcore.editor. По умолчанию применяется системный редактор. Полеcommit.templateслужит для указания шаблона, который будет задействоваться при каждом коммите.

15 Есть и много других полей, но самое полезное -alias(привязывает команду к псевдониму). К примеру, git config --global alias.st "status -s" позволит использоватьgit stвместоgit status -s.

16 А git config --list выведет все поля с их значениями из конфигурационного файла.

17 <h2>Создание Git-репозитория</h2>

18 Чтобы инициализировать новый репозиторий.gitиспользуют команду git init. Если хотите скопировать уже существующий репозиторий - git clone <адрес репозитория>.

19 <h2>История коммитов в Git</h2>

20 Git хранит имеющиеся данные в виде набора "снимков", называемыхкоммитами. Коммиты хранят состояние файловой системы в конкретный момент времени, а также имеют указатель на предыдущие коммиты. Каждый коммит содержит уникальный контрольный идентификатор, который используетсяGit, чтобы ссылаться на этот коммит. Для отслеживания истории Git хранит указательHEAD, указывающий на 1-й коммит.

21 Ссылаться можно как через контрольную сумму коммита, так и через его позицию относительно HEAD. К примеру,HEAD~4будет ссылаться на коммит, находящийся 4-мя коммитами ранее HEAD.

22 <h2>Система файлов в Git</h2>

23 Git может отслеживать файлы в 3-х основных разделах: - рабочая директория (речь идёт о файловой системе вашего ПК); - область подготовленных файлов (этоstaging area, где хранится содержание следующего коммита); -HEAD(последний в репозитории коммит).

24 <h2>Как просматривать изменения в файловых системах?</h2>

25 Для этого используют команду git status. Она отображает все файлы, которые различаются между 3-мя отделами. Файлы имеют четыре состояния: 1)untracked(неотслеживаемый). Находится в рабочей директории, но его нет ни в HEAD, ни в области подготовленных файлов. Можно сказать, что Git о нём не знает; 2)modified(изменён). В рабочей директории находится его более новая версия по сравнению с той, которая хранится в HEAD либо в области подготовленных файлов (при этом изменения не находятся в следующем коммите); 3)staged(подготовлен). В области подготовленных файлов и в рабочей директории есть более новая версия, если сравнивать с хранящейся в HEAD, но файл уже готов к коммиту; 4)без изменений. Во всех разделах содержится одна версия файла, то есть в последнем коммите находится актуальная версия.

26 Чтобы посмотреть не изменённые файлы, а непосредственно изменения, можно использовать: - git diff - для сравнения рабочей директории с областью подготовленных файлов; - git diff --staged - для сравнения области подготовленных файлов с HEAD.

27 В случае применения аргумента <файл/папка>diffпокажет изменения лишь для указанных вами папок или файлов, к примеру:

28 <h2>Игнорирование файлов</h2>

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

30 Для игнорирования предусмотрен файл.gitignore, где отмечаются файлы для игнорирования.

31 <h2>Коммиты</h2>

32 Основой истории версий являются коммиты. Для работы с ними используют git commit - эта команда откроет текстовый редактор для ввода сообщения коммита. Кроме того, она принимает следующие аргументы: •-m- позволяет написать сообщение, не открывая редактор, то есть вместе с командой; •-a- служит для переноса всех отслеживаемых файлов в область подготовленных файлов и включения их в коммит (даёт возможность перед коммитом пропуститьgit add); •--amend- заменяет последний коммит новым изменённым коммитом. Это бывает полезно, когда вы неправильно наберёте сообщение последнего коммита либо забудете включить в него нужные файлы.

33 Ряд советов по коммитам: - коммитьте часто; - одно изменение - один коммит, но не коммитьте слишком незначительные изменения (в большом репозитории они могут засорить историю); - комментируя сообщение о коммите, логически дополняйте фразуthis commit will ___и не используйте более 50 символов.

34 <h2>Удалённые серверы</h2>

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

36 Для вывода списка удалённых репозиториев нужна команда git remote -v. С её помощью мы не только загружаем копию репозитория, но и отслеживаем удалённый сервер, находящийся по указанному адресу (ему присваивается имяorigin).

37 Другие часто употребляемые команды: • git remote add <имя> <url> - добавляется удалённый репозиторий с заданным именем; • git remote remove <имя> - удаляется удалённый репозиторий с заданным именем; • git remote rename <старое имя> <новое имя> - переименовывается удалённый репозиторий; • git remote set-url <имя> <url> - репозиторию с именем присваивается новый адрес; • git remote show <имя> - показывается информация о репозитории.

38 Следующий список нужен для работы с удалёнными ветками: • git fetch <имя> <ветка> - для получения данных из ветки заданного репозитория; • git pull <имя> <ветка> - сливает данные из ветки; • git push <имя> <ветка> - для отправления изменения в ветку заданного репозитория. Когда локальная ветка отслеживает удалённую, достаточно использовать git push или git pull.

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

40 <h2>Ветвление в Git</h2>

41 Ключевая особенность Git -ветвление, позволяющее работать над разными версиями проекта. Таким образом, вместо одного перечня с упорядоченными коммитами история может расходиться в некоторых точках, поэтому становится похожей на дерево. И каждая ветвь содержит в Git легковесный указатель HEAD, указывающий на последний коммит в данной ветке. В результате можно легко создать много веток. Делая это, называйте ветки согласно разрабатываемой функциональности. Ветку по умолчанию называютmaster.

42 Что ж, у нас есть HEAD для каждой ветки и общий указатель HEAD. Переключение между ветками предполагает лишь перемещение HEAD в HEAD соответствующей ветки.

43 Стандартные команды при ветвлении вGit: • git branch <имя ветки> - для создания новой ветки с HEAD, указывающим на HEAD. Если аргумент <имя ветки> передан не будет, команда выведет список всех имеющихся локальных веток; • git branch -d <имя ветки> - для удаления ветки; • git checkout <имя ветки> - для переключения на эту ветку. Если хотим создать новую ветку перед переключением, можем передать опцию -b.

44 И локальный, и удалённый репозиторий могут иметь много веток, поэтому при отслеживании на деле отслеживается удалённая ветка, то естьgit cloneпривязывает ветвь master к ветви origin/master удалённого репозитория.

45 Парочка команд для привязывания к удалённой ветке: • git branch -u <имя удалённого репозитория>/<удалённая ветка> -текущая ветка привязывается к указанной удалённой ветке; • git checkout --track <имя удалённого репозитория>/<удалённая ветка> - аналогично; • git checkout -b <ветка> <имя удалённого репозитория>/<удалённая ветка> - создаётся новая локальная ветвь и начинает отслеживать удалённую; • git checkout <удалённая ветка> - создаётся локальная ветвь с таким же именем, как и у удалённой, плюс начинает её отслеживать; • git branch --vv - служит, чтобы показать локальные и отслеживаемые удалённые ветки.

46 <h2>Совмещение веток</h2>

47 Обсудив возможности по переключению, можно поговорить, как ветки совмещать после разработки. Ветку, в которую мы желаем слить изменения, назовём основной, а ветвь, из которой будем сливать, - тематической. Существуют 2 способа внести изменения - перемещение и слияние.

48 <h2>Слияние</h2>

49 Включает в себя создание нового коммита, основанного на общем коммите-предке 2-х ветвей, указывает на оба HEAD. Для осуществления слияния нужно перейти на основную ветки и использовать команду git merge <тематическая ветка>.

50 Когда обе ветки меняют одну и ту же часть файла, возникаетконфликт слияния. В этой ситуации Git не понимает, какую версию файла нужно сохранить. Разрешать конфликт следует вручную. Для просмотра конфликтующих файлов, используйте git status.

51 Маркеры разрешения конфликта:

52 <<<<<<< HEAD:index.html Everything above the ==== is the version in master. ======= Everything below the ==== is the version in the test branch. >>>>>>> test:index.htmlВ этом блоке надо заменить всё на версию, которую хотите оставить, после чего подготовить файл. Разрешив все конфликты, можно завершать слияние, используя git commit.

53 <h2>Перемещение</h2>

54 Осуществляется вместо совмещения 2-ух веток коммитом слияния. Перемещение заново воспроизводит коммиты тематической ветви в виде набора новых коммитов базовой ветви, что обеспечивает более чистую историю коммитов.

55 Чтобы выполнить перемещение, используют команду git rebase <основная ветка> <тематическая ветка>. Она воспроизводит изменения тематической ветви на основной. При этом HEAD тематической ветви указывает на последний воспроизведённый коммит.

56 Совет: перемещайте изменения лишь на вашей приватной локальной ветке. Не стоит перемещать коммиты, от которых ещё кто-то зависит.

57 Если хотитеоткатить коммит: - git revert <коммит> - создаёт новый коммит, который отменяет изменения, но сохраняет историю; - git reset <коммит> - перемещает указатель HEAD, и создаёт более чистую историю, как будто коммита никогда не было. Но это также значит, что вы не сможете вернуться обратно к изменениям, если решите, что отмена была лишней. В общем, чище - не значит лучше!