Лучшие практики
Коммит должен содержать связанные изменения. Например, правки двух разных багов должны быть в двух разных коммитах. Маленькие коммиты помогают другим разработчикам проще понимать изменения и откатить их, если что-то пойдет не так.
При помощи таких инструментов, как область подготовленных файлов и возможности добавлять только часть изменений из файла, Git упрощает создание очень мелких коммитов.
Делайте коммиты часто
Частая публикация коммитов позволяет вам делать их маленькими и, опять же, помогает добавлять в коммит только связанные изменения. Более того, почаще делитесь своим кодом с остальными. Таким образом, всем будет легче, если вы чаще будете интегрировать свои изменения и это поможет избежать конфликтов при слиянии. Большие и редкие коммиты усложняют жизнь и затрудняет решение конфликтов.
Не публикуйте коммиты с незаконченной работой
Вы должны коммитить код, только если он завершен. Это не значит, что вы должны полностью закончить работу над большой задачей перед коммитом. Наоборот: разделите работу над задачей на логические части и помните о своевременной и частой публикации коммитов. Но не публикуйте изменения только чтобы в репозитории что-то появилось перед вашим уходом из офиса в конце рабочего дня. Если вы собираетесь опубликовать коммит только потому, что вам нужна чистая рабочая область (при переключении веток, перед pull и т.д.) присмотритесь к функци “stash”.
Тестируйте код перед коммитом
Не поддавайтесь искушению закоммитить что-то, что на ваш взгляд уже готово. Протестируйте внимательно и убедитесь в том, что работа закончена и в коде нет ошибок (на сколько это может проверить один человек). В то время, как полусырые изменения в вашем локальном репозитории вы можете простить себе самому, вы должны тщательно протестировать код перед тем как публиковать/делится своим кодом с другими.
Пишите хорошие комментарии
Начните свое сообщение с краткого резюме своих изменений (ориентируйтесь на 50 символов). Отделите это сообщение от основного текста пустой строкой. В теле сообщения следует дать подробные ответы на следующие вопросы:
- Какова была причина изменений?
- В чем отличие от предыдущего коммита?
Используйте слова в настоящем времени («меняется», не «был изменен» или «изменения») чтобы при git merge сгенерированное сообщение выглядело хорошо.
Система контроля версий не хранилище бекапов
Хранение резервных копий файлов на удаленном сервере это только приятный побочный эффект использования системы контроля версий. Но вы не должны использовать Git только для этого. При работе с системой обратите особое внимание на семантику коммитов (смотри пункт 1) — вы не должны просто запихивать файлы в репозиторий.
Используйте ветки
Ветвление — это одна из самых мощных возможностей Git. И это не случайно: быстрое и простое ветвление было требованием номер один с самого начала. Ветки являются самым простым инструментом чтобы избежать смешивания разных линий разработки. Вы должны повсеместно использовать ветки в своей разработке: для работы над новыми задачами, для исправления багов, для идей…
Согласуйте рабочий процесс
Git позволяет выбрать из большого количества рабочих процессов: длинные ветки, тематические ветки, слияние или перемещение, gitflow… Что из этого выберите вы зависит от нескольких факторов: ваш проект, ваше общее направление развития, среда разработки и (возможно самое важное) ваши личные предпочтения и предпочтения вашей команды. Что бы вы не выбрали убедитесь, что все следуют процессу, который был согласован.
Git: наглядная справка
Если вы не видите иллюстраций, попробуйте переключиться на версию со стандартными картинками (без SVG).
SVG изображения были отключены. (Включить SVG изображения)
На этой странице представлена краткая наглядная справка для наиболее часто используемых команд git. Если у вас уже есть небольшой опыт работы с git, эта страница поможет вам закрепить ваши знания. Если вам интересно, как был создан этот сайт, загляните на мой репозиторий на GitHub.
Содержание
Основные команды
Следующие четыре команды предназначены для копирования файлов между рабочей директорией, сценой, также известной как «индекс», и историей, представленной в форме коммитов.
- git add файлы копирует файлы в их текущем состоянии на сцену.
- git commit сохраняет снимок сцены в виде коммита.
- git reset — файлы восстанавливает файлы на сцене, а именно копирует файлы из последнего коммита на сцену. Используйте эту команду для отмены изменений, внесённых командой git add файлы . Вы также можете выполнить git reset , чтобы восстановить все файлы на сцене.
- git checkout — файлы копирует файлы со сцены в рабочую директорию. Эту команду удобно использовать, чтобы сбросить нежелательные изменения в рабочей директории.
Вы можете использовать git reset -p , git checkout -p , и git add -p вместо имён файлов или вместе с ними, чтобы в интерактивном режиме выбирать, какие именно изменения будут скопированы.
Также можно перепрыгнуть через сцену и сразу же получить файлы из истории прямо в рабочую директорию или сделать коммит, минуя сцену.
- git commit -a аналогичен запуску двух команд: git add для всех файлов, которые существовали в предыдущем коммите, и git commit.
- git commit файлы создаёт новый коммит, в основе которого лежат уже существующие файлы, добавляя изменения только для указанных файлов. Одновременно, указанные файлы будут скопированы на сцену.
- git checkout HEAD — файлы копирует файлы из текущего коммита и на сцену, и в рабочую директорию.
Соглашения
Иллюстрации в этой справке выдержаны в единой цветовой схеме.
Коммиты раскрашены зелёным цветом и подписаны 5-ти буквенными идентификаторами. Каждый коммит указывает на своего родителя зелёной стрелочкой. Ветки раскрашены оранжевым цветом; ветки указывают на коммиты. Специальная ссылка HEAD указывает на текущую ветку. На иллюстрации вы можете увидеть последние пять коммитов. Самый последний коммит имеет хеш ed489. main (текущая ветка) указывает на этот коммит, stable (другая ветка) указывает на предка main-ового коммита.
Подробно о командах
Есть много способов посмотреть изменения между коммитами. Ниже вы увидите несколько простых примеров. К каждой из этих команд можно добавить имена файлов в качестве дополнительного аргумента. Так мы выведем информацию об изменениях только для перечисленных файлов.
Commit
Когда вы делаете коммит, git создаёт новый объект коммита, используя файлы со сцены, а текущей коммит становится родителем для нового. После этого указатель текущей ветки перемещается на новый коммит. Вы это видите на картинке, где main — это текущая ветка. До совершения коммита main указывал на коммит ed489. После добавления нового коммита f0cec, родителем которого стал ed489, указатель ветки main был перемещён на новый коммит.
То же самое происходит, если одна ветка является предком другой ветки. Ниже показан пример нового коммита 1800b в ветке stable, которая является предком ветки main. После этого ветка stable уже больше не является предком ветки main. И в случае необходимости объединения работы, проделанной в этих разделённых ветках, вам следует воспользоваться командой merge (что более предпочтительно) или rebase.
Если вы сделали ошибку в последнем коммите, её легко исправить с помощью команды git commit —amend . Эта команда создаёт новый коммит, родителем которого будет родитель ошибочного коммита. Старый ошибочный коммит будет отброшен, конечно же если только на него не будет ещё каких-либо других ссылок, что маловероятно.
Четвертый случай коммита из состояния «detached HEAD» будет рассмотрен далее.
Checkout
Команда checkout используется для копирования файлов из истории или сцены в рабочую директорию. Также она может использоваться для переключения между ветками.
Когда вы указываете имя файла (и/или ключ -p ), git копирует эти файлы из указанного коммита на сцену и в рабочую директорию. Например, git checkout HEAD
foo.c копирует файл foo.c из коммита HEAD
(предка текущего коммита) в рабочую директорию и на сцену. Если имя коммита не указано, то файл будет скопирован со сцены в рабочую директорию. Обратите внимание на то, что при выполнении команды checkout позиция указателя текущей ветки (HEAD) остаётся прежней, указатель никуда не перемещается.
В том случае, если мы не указываем имя файла, но указываем имя локальной ветки, то указатель HEAD будет перемещён на эту ветку, то есть мы переключимся на эту ветку. При этом сцена и рабочая директория будут приведены в соответствие с этим коммитом. Любой файл, который присутствует в новом коммите (a47c3 ниже), будет скопирован из истории; любой файл, который был в старом коммите (ed489), но отсутствует в новом, будет удалён; любой файл, который не записан ни в одном коммите, будет проигнорирован.
В том случае, если мы не указываем имя файла, и не указываем имя локальной ветки, а указываем тег, дистанционную (remote) ветку, SHA-1 хеш коммита или что-то вроде main
3, то мы получаем безымянную ветку, называемую «Detached HEAD» (оторванная голова). Это очень полезная штука, если нам надо осмотреться в истории коммитов. К примеру, вам захочется скомпилировать git версии 1.6.6.1. Вы можете набрать git checkout v1.6.6.1 (это тег, не ветка), скомпилировать, установить, а затем вернуться в другую ветку, скажем git checkout main . Тем не менее, коммиты из состояния «Detached HEAD» происходят по своим особым важным правилам, и мы рассмотрим их ниже.
Коммит из состояния «Detached HEAD»
Когда мы находимся в состоянии оторванной головы (Detached HEAD), коммит совершается по тем же правилам, что и обычно, за исключением одной маленькой особенности: ни один указатель ветки не будет изменён или добавлен к новому коммиту. Вы можете представить эту ситуацию как работу с анонимной веткой.
Если после такого коммита вы переключитесь в ветку main, то коммит 2eecb, совершённый из состояния «Detached HEAD», потеряется и попросту будет уничтожен очередной сборкой мусора только потому, что нет ни одного объекта, который бы на него ссылался: ни ветки, ни тега.
В том случае, если вы хотите сохранить этот коммит на будущее, вы можете создать на основе него новую ветку командой git checkout -b new .
Reset
Команда reset перемещает указатель текущей ветки в другую позицию и дополнительно может обновить сцену и рабочую директорию. Эту команду можно также использовать для того, чтобы скопировать файл из истории на сцену, не задевая рабочую директорию.
Если коммит указан без имён файлов, указатель ветки будет перемещён на этот коммит, а затем сцена приведётся в соответствие с этим коммитом. Если мы используем ключ —soft , то сцена не будет изменена. Если мы используем ключ —hard , то будет обновлена и сцена, и рабочая директория.
Если имя коммита не будет указано, по умолчанию оно будет HEAD. В этом случае указатель ветки не будет перемещён, но сцена (а также и рабочая директория, если был использован ключ —hard ) будет приведена к состоянию последнего коммита.
Если в команде указано имя файла (и/или ключ -p ), то команда работает так же, как checkout с именем файла, за исключением того, что только сцена (но не рабочая директория) будет изменена. Если вы подставите имя коммита на место двойной черты, вы сможете получить состояние файла из этого коммита, тогда как в случае с двойной чертой вы получите состояние файла из коммита, на который указывает HEAD.
Merge
Команда merge (слияние) создает новый коммит на основе текущего коммита, применяя изменения других коммитов. Перед слиянием сцена должна быть приведена в соответствие с текущим коммитом. Самый простой случай слияния — это когда другой коммит является предком текущего коммита: в этом случае ничего не происходит. Другой простой случай слияния — когда текущий коммит является предком другого коммита: в этом случае происходит быстрая перемотка (fast-forward). Ссылка текущей ветки будет просто перемещена на новый коммит, а сцена и рабочая директория будут приведены в соответствие с новым коммитом.
Во всех других случаях выполняется «настоящее» слияние. Вы можете изменить стратегию слияния, но по умолчанию будет выполнено «рекурсивное» слияние, для которого будет взят текущий коммит (ed489 ниже на схеме), другой коммит (33104) и их общий предок (b325c); и для этих трех коммитов будет выполнено трёхстороннее слияние. Результат этого слияния будет записан в рабочую директорию и на сцену, и будет добавлен результирующий коммит со вторым родителем (33104).
Cherry Pick
Команда cherry-pick («вишенка в тортике») создаёт новый коммит на основе только одного сладкого «коммита-вишенки», применив все его изменения и сообщение.
Rebase
Перебазирование (rebase) — это альтернатива слиянию для задач объединения нескольких веток. Если слияние создаёт новый коммит с двумя родителями, оставляя нелинейную историю, то перебазирование применяет все коммиты один за одним из одной ветки в другую, оставляя за собой линейную историю коммитов. По сути это автоматическое выполнение нескольких команд cherry-pick подряд.
На схеме выше вы видите как команда берёт все коммиты, которые есть в ветке topic, но отсутствуют в ветке main (коммиты 169a6 and 2c33a), и воспроизводит их в ветке main. Затем указатель ветки перемещается на новое место. Следует заметить, что старые коммиты будут уничтожены сборщиком мусора, если на них уже ничего не будет ссылаться.
Используйте ключ —onto чтобы ограничить глубину захвата объединяемой ветки. На следующей схеме вы можете увидеть как в ветку main приходят лишь последние коммиты из текущей ветки, а именно коммиты после (но не включая) 169a6, т. е. 2c33a.
Есть также интерактивный режим перебазирования git rebase —interactive , с помощью которого вы сможете сделать вещи похитрее простого линейного применения коммитов, а именно сбрасывание (dropping), изменение порядка (reordering), правка (modifying) и выдавливание (squashing) коммитов. Нет наглядной схемы, чтобы показать эти возможности; за описанием лучше обратиться к справке по git-rebase(1).
Технические заметки
Содержание файлов не хранится в индексе (.git/index) или в объектах коммитов. Правильнее было бы сказать, что каждый файл хранится в базе данных объектов (.git/objects) в двоичном представлении; найти этот файл можно по его SHA-1 хешу. В файле индекса записаны имена файлов, их хеши и дополнительная информация. В информации о коммитах вы встретите тип данных дерево, для идентификации которого также используется SHA-1 хеш. Деревья описывают директории в рабочей директории, а также содержат информацию о других деревьях и файлах, принадлежащих обозначенному дереву. Каждый коммит хранит идентификатор своего верхнего дерева, которое содержит все файлы и другие деревья, изменённые в этом коммите.
Если вы делаете коммит из состояния «оторванной головы» (detached HEAD), то на этот коммит будет ссылаться ссылка истории HEAD. Но рано или поздно время хранения этой ссылки истечёт, и этот коммит будет уничтожен сборщиком мусора точно так же, как это делается при выполнении команд git commit —amend и git rebase .
Copyright © 2010, Mark Lodato. Russian translation © 2012, Alex Sychev.
/> Это произведение доступно по лицензии Creative Commons Attribution-NonCommercial-ShareAlike (Атрибуция — Некоммерческое использование — С сохранением условий) 3.0 США.
Pushing commits to a remote repository
Use git push to push commits made on your local branch to a remote repository.
Команда git push принимает два аргумента:
- имя удаленного репозитория, например, origin ;
- Имя ветви, например main
Например, вы обычно выполняете команду git push origin main для отправки локальных изменений в веб-репозиторий.
Чтобы переименовать ветвь, используйте ту же команду git push , добавив к ней еще один аргумент: имя новой ветви. Пример:
LOCAL-BRANCH-NAME отправляется в REMOTE-NAME , но при этом переименовывается в REMOTE-BRANCH-NAME .
Обработка ошибок не быстрого перемещения вперед
Если локальная копия репозитория не синхронизирована с вышестоящим репозиторием, в который выполняется отправка, вы получите следующее сообщение: non-fast-forward updates were rejected . В таком случае перед отправкой локальных изменений необходимо извлечь или «получить» изменения из вышестоящего репозитория.
Дополнительные сведения об этой ошибке см. в разделе Обработка ошибок не быстрого перемещения вперед.
По умолчанию команда git push без дополнительных параметров отправляет все ветви, имена которых соответствуют именам удаленных ветвей.
Чтобы отправить отдельный тег, можно использовать ту же команду, что и для отправки ветви:
Чтобы отправить все теги, можно ввести следующую команду:
Удаление удаленных ветви или тега
На первый взгляд синтаксис удаления ветви может показаться непонятным:
Обратите внимание на пробел, стоящий перед двоеточием. Эта команда напоминает ту, которая используется для переименования ветви. Тем не менее, она указывает Git выполнить пустую отправку в ветвь BRANCH-NAME в репозитории REMOTE-NAME . Таким образом, команда git push удаляет ветвь в удаленном репозитории.
Удаленные репозитории и вилки
Безусловно, вы уже знаете, что на GitHub можно создавать «вилки» репозиториев.
При клонировании собственного репозитория вы предоставляете ему удаленный URL-адрес, который Git использует для получения и отправки обновлений. Для совместной работы с исходным репозиторием следует добавить в локальный клон Git новый удаленный URL-адрес (обычно называется upstream ):
Теперь вы можете получать обновления и ветви из их вилки:
После внесения локальных изменений вы можете отправить локальную ветвь в GitHub и инициировать запрос на вытягивание.
30 команд Git, необходимых для освоения интерфейса командной строки Git
Git — самая популярная в мире распределённая система контроля версий. Линус Торвальдс, разработчик ядра ОС Linux, создал этот инструмент ещё в 2005 году, а сегодня Git активно поддерживается как проект с открытым исходным кодом. Огромное количество открытых и коммерческих проектов используют Git для контроля версий.
В данной статье перечисляются самые основные команды, которые следует знать разработчику, чтобы освоить управление репозиториями GitHub на высоком уровне. Ознакомиться с ними будет полезно как новичкам, так и опытным разработчикам.
30 основных команд, которые сделают из вас мастера Git
1. Как задать имя пользователя и адрес электронной почты
Имя пользователя нужно, чтобы привязывать коммиты к вашему имени. Это не то же самое, что имя пользователя учётной записи GitHub, с помощью которого выполняется вход в профиль на GitHub. Задать или изменить имя пользователя можно с помощью команды git config . Новое имя будет автоматически отображаться в последующих коммитах, отправленных на GitHub через командную строку. Если хотите скрыть своё реальное имя, можно использовать в качестве имени пользователя Git произвольный набор символов.
Кроме того, командой git config можно изменять адрес электронной почты, привязанный к вашим коммитам Git. Новый адрес электронной почты будет автоматически отображаться во всех дальнейших коммитах, поданных на GitHub через командную строку.
2. Кэширование учётных данных
Кэшировать учётные данные можно с помощью параметра config с флагом —global . Так вы избавитесь от необходимости вручную вводить имя пользователя и пароль при создании нового коммита.
3. Инициализация репозитория
Создать пустой репозиторий Git или вновь инициализировать существующий можно параметром init . При инициализации он создаст скрытую папку. В ней содержатся все объекты и ссылки, которые Git использует и создаёт в истории работы над проектом.
4. Добавление отдельных файлов или всех файлов в область подготовленных файлов
Добавить отдельный файл в область подготовленных файлов можно параметром add с указанием имени файла. Просто замените somefile.js на актуальное имя.
Кроме того, можно добавить все файлы и папки в эту область, предоставив wildcard . вместо имени файла:
5. Проверка статуса репозитория
Просмотреть статус нужного репозитория можно по ключевому слову status : его действие распространяется на подготовленные, неподготовленные и неотслеживаемые файлы.
6. Внесение изменений однострочным сообщением или через редактор
При создании коммита в репозитории можно добавить однострочное сообщение с помощью параметра commit с флагом -m . Само сообщение вводится непосредственно после флага, в кавычках.
Также можно открыть текстовый редактор в терминале для написания полного сообщения коммита. Оно может состоять из нескольких строк текста, в котором подробно характеризуются изменения, внесённые в репозиторий.
7. Просмотр истории коммитов с изменениями
Просматривать изменения, внесённые в репозиторий, можно с помощью параметра log . Он отображает список последних коммитов в порядке выполнения. Кроме того, добавив флаг -p , вы можете подробно изучить изменения, внесённые в каждый файл.
8. Просмотр заданного коммита
Просмотреть полный список изменений, внесённых конкретным коммитом, можно с помощью параметра show , указав идентификатор или хеш коммита. Значение хеша уникально для каждого коммита, созданного в вашем репозитории.
Также можно использовать сокращённый хеш.
9. Просмотр изменений до коммита
Можно просматривать список изменений, внесённых в репозиторий, используя параметр diff . По умолчанию отображаются только изменения, не подготовленные для фиксации.
Для просмотра подготовленных изменений необходимо добавить флаг —staged .
Также можно указать имя файла как параметр и просмотреть изменения, внесённые только в этот файл.
10. Удаление отслеживаемых файлов из текущего рабочего дерева
Удалять файлы из текущего рабочего дерева можно с помощью параметра rm . При этом файлы удаляются и из индекса.
Можно также использовать маски файлов (например *.js) для удаления всех файлов, соответствующих критерию.
11. Переименование файлов
Переименовать файл или папку можно параметром mv . Для него указывается источник source и назначение destination . Источник — реально существующий файл или папка, а назначение — существующая папка.
При выполнении команды файл или папка, указанные как источник, будут перемещены в папку назначения. Индекс будет обновлён соответственно, но изменения нужно записать.
12. Отмена подготовленных и неподготовленных изменений
Восстановить файлы рабочего дерева, не подготовленные к коммиту, можно параметром checkout . Для проведения операции требуется указать путь к файлу. Если путь не указан, параметр git checkout изменит указатель HEAD, чтобы задать указанную ветку как текущую.
Восстановить подготовленный файл рабочего дерева можно параметром reset . Потребуется указать путь к файлу, чтобы убрать его из области подготовленных файлов. При этом не будет производиться откат никаких изменений или модификаций — однако файл перейдёт в категорию не подготовленных к коммиту.
Если нужно выполнить это действие для всех подготовленных файлов, путь к ним указывать не надо.
13. Изменение последнего коммита
Внести изменения в последний коммит можно параметром commit с флагом —amend . Например, вы записали изменения, внесённые в ряд файлов, и поняли, что допустили ошибку в сообщении коммита. В этом случае можете воспользоваться указанной командой, чтобы отредактировать сообщение предыдущего коммита, не изменяя его снимок.
Также можно вносить изменения в файлы, отправленные ранее. Например, вы изменили несколько файлов в ряде папок и хотите их записать как единый снимок, но забыли добавить в коммит одну из папок. Чтобы исправить такую ошибку, достаточно подготовить для фиксации остальные файлы и папки и создать коммит с флагами —amend и —no-edit .
Флаг —no-edit позволит внести в коммит поправку без изменения сообщения коммита. В этом случае итоговый коммит заменит неполный, а выглядеть это будет так, как будто мы отправили изменения ко всем файлам в нужных папках как единый снимок.
Внимание! Не изменяйте публичные коммиты.
С помощью amend прекрасно исправляются локальные коммиты, а исправления можно передать в общий репозиторий. Однако изменять коммиты, уже доступные другим пользователям, не следует. Помните, что изменённые коммиты являются совершенно новыми, а предыдущий коммит уже не будет доступен в текущей ветке. Последствия будут такими же, как при отмене изменений публичного снимка.
14. Откат последнего коммита
Откатить последний коммит можно с помощью параметра revert . Создастся новый коммит, содержащий обратные преобразования относительно предыдущего, и добавится к истории текущей ветки.
▍ Разница между revert и reset
Команда git revert отменяет изменения, записанные только одним коммитом. Она не откатывает проект к более раннему состоянию, удаляя все последующие коммиты, как это делает команда git reset .
У команды revert есть два крупных преимущества по сравнению с reset. Во-первых, она не меняет историю проекта и производит операцию, безопасную для коммитов. Во-вторых, её объектом выступает конкретный коммит, созданный в любой момент истории, а git reset всегда берёт за точку отсчёта текущий коммит. К примеру, если нужно отменить старый коммит с помощью git reset, придётся удалить все коммиты, поданные после целевого, а затем выполнить их повторно. Следовательно, команда git revert — гораздо более удобный и безопасный способ отмены изменений.
15. Откат заданного коммита
Откатить проект до заданного коммита можно с помощью параметра revert и идентификатора коммита. Создастся новый коммит — копия коммита с предоставленным идентификатором — и добавится к истории текущей ветки.
16. Создание новой ветки и переход в неё
Создать новую ветку можно с помощью параметра branch , указав имя ветки.
Но Git не переключится на неё автоматически. Для автоматического перехода нужно добавить флаг -b и параметр checkout .
17. Просмотр списка веток
Можно просматривать полный список веток, используя параметр branch . Команда отобразит все ветки, отметит текущую звёздочкой (*) и выделит её цветом.
Также можно вывести список удалённых веток с помощью флага -a .
18. Удаление ветки
Удалить ветку можно параметром branch с добавлением флага -d и указанием имени ветки. Если вы завершили работу над веткой и объединили её с основной, можно её удалить без потери истории. Однако, если выполнить команду удаления до слияния — в результате появится сообщение об ошибке. Этот защитный механизм предотвращает потерю доступа к файлам.
Для принудительного удаления ветки используется флаг -D с заглавной буквой. В этом случае ветка будет удалена независимо от текущего статуса, без предупреждений.
Вышеуказанные команды удаляют только локальную копию ветки. В удалённом репозитории она может сохраниться. Если хотите стереть удалённую ветку, выполните следующую команду:
19. Слияние двух веток
Объединить две ветки можно параметром merge с указанием имени ветки. Команда объединит указанную ветку с основной.
Если надо выполнить коммит слияния, выполните команду git merge с флагом —no-ff .
Указанная команда объединит заданную ветку с основной и произведёт коммит слияния. Это необходимо для фиксации всех слияний в вашем репозитории.
20. Отображение журнала фиксации в виде графика для текущей или всех веток
Просмотреть историю коммитов в виде графика для текущей ветки можно с помощью параметра log и флагов —graph —oneline —decorate . Опция —graph выведет график в формате ASCII, отражающий структуру ветвления истории коммитов. В связке с флагами —oneline и —decorate , этот флаг упрощает понимание того, к какой ветке относится каждый коммит.
Для просмотра истории коммитов по всем веткам используется флаг —all .
21. Прекращение слияния при конфликте
Прервать слияние в случае конфликта можно параметром merge с флагом —abort . Он позволяет остановить процесс слияния и вернуть состояние, с которого этот процесс был начат.
Также при конфликте слияния можно использовать параметр reset , чтобы восстановить конфликтующие файлы до стабильного состояния.
22. Добавление удалённого репозитория
Добавить удалённый репозиторий можно параметром remote add , указав shortname и url требуемого репозитория.
23. Просмотр удалённых URL-адресов
Просматривать удалённые URL-адреса можно параметром remote с флагом -v . Этот параметр отображает удалённые подключения к другим репозиториям.
Такая команда открывает доступ к интерфейсу управления удалёнными записями, которые хранятся в файле .git/config репозитория.
24. Получение дополнительных сведений об удалённом репозитории
Получить подробные сведения об удалённом репозитории можно с помощью параметра remote show с указанием имени репозитория — например, origin .
Эта команда отображает список веток, связанных с удалённым репозиторием, а также рабочих станций, подключённых для получения и отправки файлов.
25. Отправка изменений в удалённый репозиторий
Отправлять изменения в удалённый репозиторий можно параметром push с указанием имени репозитория и ветки.
Эта команда передаёт локальные изменения в центральный репозиторий, где с ними могут ознакомиться другие участники проекта.
26. Получение изменений из удалённого репозитория
Для загрузки изменений из удалённого репозитория используется параметр pull . Он скачивает копию текущей ветки с указанного удалённого репозитория и объединяет её с локальной копией.
Также можно просмотреть подробные сведения о загруженных файлах с помощью флага —verbose .
27. Слияние удалённого репозитория с локальным
Слияние удалённого репозитория с локальным выполняется параметром merge с указанием имени удалённого репозитория.
28. Отправка новой ветки в удалённый репозиторий
Передать новую ветку в удалённый репозиторий можно параметром push с флагом -u , указав имя репозитория и имя ветки.
29. Удаление удалённой ветки
Чтобы избавиться от удалённой ветки, используйте параметр push с флагом —delete , указав имя удалённого репозитория и имя ветки.
30. Использование перебазирования
Для доступа к этой функции используйте параметр rebase с указанием имени ветки. Перебазирование — это процесс объединения или перемещения последовательности коммитов на новый родительский снимок.
Эта команда изменит основу ветки с одного коммита на другой, как если бы вы начали ветку с другого коммита. В Git это достигается за счёт создания новых коммитов и применения их к указанному базовому коммиту. Необходимо понимать, что, хотя ветка и выглядит такой же, она состоит из совершенно новых коммитов.
▍ Спасибо за внимание!
Вы узнали 30 основных команд интерфейса командной строки Git. Теперь, при условии регулярной практики, у вас есть всё необходимое, чтобы достичь мастерства в управлении репозиториями GitHub.