Git checkout branch что делает
Check your version of git by running
SYNOPSIS
DESCRIPTION
Updates files in the working tree to match the version in the index or the specified tree. If no pathspec was given, git checkout will also update HEAD to set the specified branch as the current branch.
To prepare for working on
, switch to it by updating the index and the files in the working tree, and by pointing HEAD at the branch. Local modifications to the files in the working tree are kept, so that they can be committed to the
.
You could omit
, in which case the command degenerates to «check out the current branch», which is a glorified no-op with rather expensive side-effects to show only the tracking information, if exists, for the current branch.
that is to say, the branch is not reset/created unless «git checkout» is successful.
Omitting
detaches HEAD at the tip of the current branch.
Overwrite the contents of the files that match the pathspec. When the
OPTIONS
Quiet, suppress feedback messages.
When checking out paths from the index, do not fail upon unmerged entries; instead, unmerged entries are ignored.
When checking out paths from the index, check out stage #2 (ours) or #3 (theirs) for unmerged paths.
This is because rebase is used in a workflow that treats the history at the remote as the shared canonical one, and treats the work done on the branch you are rebasing as the third-party work to be integrated, and you are temporarily assuming the role of the keeper of the canonical history during the rebase. As the keeper of the canonical history, you need to view the history from the remote as ours (i.e. «our shared canonical history»), while what you did on your side branch as theirs (i.e. «one contributor’s work on top of it»).
Create a new branch named and start it at ; see git-branch[1] for details.
When creating a new branch, set up «upstream» configuration. See «—track» in git-branch[1] for details.
Do not set up «upstream» configuration, even if the branch.autoSetupMerge configuration variable is true.
If
is not found but there does exist a tracking branch in exactly one remote (call it ) with a matching name, treat as equivalent to
If the branch exists in multiple remotes and one of them is named by the checkout.defaultRemote configuration variable, we’ll use that one for the purposes of disambiguation, even if the
isn’t unique across all remotes. Set it to e.g. checkout.defaultRemote=origin to always checkout remote branches from there if
is ambiguous but exists on the origin remote. See also checkout.defaultRemote in git-config[1].
The default behavior can be set via the checkout.guess configuration variable.
Create the new branch’s reflog; see git-branch[1] for details.
Rather than checking out a branch to work on it, check out a commit for inspection and discardable experiments. This is the default behavior of git checkout when is not a branch name. See the «DETACHED HEAD» section below for details.
This can be useful when you want to publish the tree from a commit without exposing its full history. You might want to do this to publish an open source branch of a project whose current tree is «clean», but whose full history contains proprietary or otherwise encumbered bits of code.
would update only entries matched by
When switching branches, if you have local modifications to one or more files that are different between the current branch and the branch to which you are switching, the command refuses to switch branches in order to preserve your modifications in context. However, with this option, a three-way merge between the current branch, your working tree contents, and the new branch is done, and you will be on the new branch.
When a merge conflict happens, the index entries for conflicting paths are left unmerged, and you need to resolve the conflicts and mark the resolved paths with git add (or git rm if the merge should result in deletion of the path).
When checking out paths from the index, this option lets you recreate the conflicted merge in the specified paths.
Interactively select hunks in the difference between the
git checkout refuses when the wanted ref is already checked out by another worktree. This option makes it check the ref out anyway. In other words, the ref can be held by more than one worktree.
Branch to checkout; if it refers to a branch (i.e., a name that, when prepended with «refs/heads/», is a valid ref), then that branch is checked out. Otherwise, if it refers to a valid commit, your HEAD becomes «detached» and you are no longer on any branch (see below for details).
Name for the new branch.
Tree to checkout from (when paths are given). If not specified, the index will be used.
Do not interpret any more arguments as options.
Limits the paths affected by the operation.
For more details, see the pathspec entry in gitglossary[7].
DETACHED HEAD
HEAD normally refers to a named branch (e.g. master ). Meanwhile, each branch refers to a specific commit. Let’s look at a repo with three commits, one of them tagged, and with branch master checked out:
It is sometimes useful to be able to checkout a commit that is not at the tip of any named branch, or even to create a new commit that is not referenced by a named branch. Let’s look at what happens when we checkout commit b (here we show two ways this may be done):
In fact, we can perform all the normal Git operations. But, let’s look at what happens when we then checkout master :
ARGUMENT DISAMBIGUATION
if you want to checkout these paths out of the index.
EXAMPLES
The following sequence checks out the master branch, reverts the Makefile to two revisions back, deletes hello.c by mistake, and gets it back from the index.
take a file out of another commit
restore hello.c from the index
If you want to check out all C source files out of the index, you can say
After working in the wrong branch, switching to the correct branch would be done using:
However, your «wrong» branch and correct mytopic branch may differ in files that you have modified locally, in which case the above checkout would fail like this:
After this three-way merge, the local modifications are not registered in your index file, so git diff would show you what changes you made since the tip of the new branch.
At this point, git diff shows the changes cleanly merged as in the previous example, as well as the changes in the conflicted files. Edit and resolve the conflict and mark it resolved with git add as usual:
Git. Урок 3.
Ветвление. Создание, переключение и удаление веток. Команды: branch, checkout, status, log, diff.
1. Что такое ветка.
2. Зачем нужны ветки.
3. Создание новых веток.
4. Просмотр списка веток.
5. Переключение между ветками.
6. Просмотр состояния ветки. Команды: git status, git log, git diff.
6.1. Просмотр состояния файлов ветки. Команда git status.
6.2. Просмотр истории коммитов ветки. Команда git log.
6.3. Просмотр различий между коммитами. Команда git diff.
7. Удаление веток.
Дадим два определения ветки: на логическом и физическом уровнях.
1. Логический уровень.
С точки зрения логики, ветка – это последовательность коммитов. Чтобы проще было понять, что такое ветка, рассматривайте ее как некоторую временную шкалу. Коммиты в ней – снимки интересных моментов, идущие друг за другом в хронологической последовательности. Рисунок ниже поможет вам в интуитивном представлении.
2. Физический уровень
На физическом уровне, то есть с точки зрения внутренней реализации Git, ветка – это ссылка на последний коммит в этой ветке. Картинка ниже поможет вам понять, что к чему.
Преимущество веток в их независимости. Вы можете вносить изменения в файлы в одной ветке, например, пробовать новую функцию, и они никак не скажутся на файлах в другой ветке. Изначально в репозитории одна ветка, но позже мы рассмотрим, как создавать другие.
На самом деле, вначале, когда мы делаем свой первый коммит, Git автоматически создает основную ветку. Вы можете помнить, что ее имя по умолчанию «main» мы задавали в настройках Git в предыдущем уроке. Каждый раз, когда мы создаем новый коммит, Git автоматически перемещает указатель main на последний коммит. Тем не менее, в следующем уроке мы узнаем, как перемещать указатель ветки между коммитами самостоятельно.
Пока мы разбирались, что такое ветка, у вас мог возникнуть вопрос: зачем нужны такие сложности, ведь можно просто делать коммиты и откатывать изменения, когда нужно.
Дело в том, что Git – универсальная система контроля версий: она подходит и большим командам крупных корпораций, и индивидуальным разработчикам для их личных проектов.
Если вы работаете один – скорее всего вы будете редко использовать ветки, но если вы работаете в большой компании, без веток вам не обойтись.
Итак, чаще всего ветки используются в следующих случаях.
Способ 1. Команды git branch + git checkout
Команда git branch
На самом деле, git branch – очень мощная команда, которая умеет много всего. Сейчас мы рассматриваем ее как инструмент для создания веток. Ниже мы рассмотрим еще некоторые способы ее применения.
Команда git checkout
40 шестнадцатеричных цифр в файле выше и есть хэш последнего коммита, на который указывает новосозданная ветка.
С помощью команд git branch и git checkout вы можете создать неограниченное количество веток и переключаться между ними по мере необходимости. Обычно если ветка вам больше не нужна, ее сливают с основной и удаляют. Тема слияния веток заслуживает отдельного урока, поэтому про это мы поговорим в следующий раз, а удаление веток рассмотрим чуть ниже.
Команда git branch
# Теперь выведем только локальные ветки
$ git branch
* develop
feature
main
Теперь, когда мы поняли, как можно узнать имена веток в репозитории, давайте научимся переключаться между ними.
Команда git checkout
Этот маленький фокус позволит вам сэкономить время, особенно, если вы часто переключаетесь между ветками.
Шаг 1. Проверка существования ветки
Нужен этот этап, чтобы случайно не переключиться на ветку, которой не существует. Чтобы понять, как происходит этот процесс, нужно сделать небольшое отступление и рассказать, как вообще Git хранит информацию о существующих ветках.
Шаг 2. Переключение HEAD на нужную ветку
Шаг 3. Изменение рабочей копии
У внимательного читателя мог возникнуть вопрос: почему файлы в рабочей копии подгружаются именно из последнего коммита ветки? Что если до переключения с данной ветки, в ней были какие-то изменения, еще не добавленные в коммит? Что с ними будет? Ответ довольно прост. Согласно трем шагам, указанным выше, Git просто проигнорирует все такие файлы. То есть они останутся в вашей рабочей копии в том же состоянии, в котором и были до этого. Как правило, такое поведение очень неудобно, поскольку позволяет легко запутаться в структуре собственного проекта. Представьте: у вас два параллельных релиза, а вы, переключаясь между ветками, случайно занесли файлы одного релиза в ветку другого.
6.1. Просмотр состояния файлов ветки. Команда git status.
6.2. Просмотр истории коммитов ветки. Команда git log.
Команда git log
-p
Показывает изменения, сделанные в данном коммите.
—graph
Рисует ASCII-граф взаимосвязи коммитов.
—all
Выводит историю всех имеющихся коммитов на всех ветках.
adding complex algebra project
commit 603def20e5da2d512da2852011eb5be3fa156940 (origin/main, origin/HEAD)
Author: smartiqa
Date: Fri Dec 4 02:00:41 2020 +0300
В описании команды git log выше сказано, что в зависимости от ситуации, она может вывести полную историю репозитория, или же только историю некоторых коммитов. Давайте разбираться, как работает Git при выводе истории.
Общее правило, которым руководствуется Git при выводе истории, такое: иди по предкам коммитов, пока они не закончатся. Иногда это бывает удобно, иногда – нет.
Давайте разберемся, что делать, если мы хотим просмотреть историю коммитов только внутри какой-то конкретной ветки. То есть историю от момента создания ветки, до последнего коммита в ней. В этом случае нужно сделать следующее:
Git checkout
Переключение веток аналогично переключению старых коммитов и файлов, в которых рабочий каталог обновляется в соответствии с выбранной веткой/ревизией; вместе с тем новые изменения сохраняются в истории проекта, то есть это не просто операция чтения.
Переключение веток
Наличие выделенной ветки для каждой новой функции сильно отличается от традиционного рабочего процесса в SVN. Это значительно облегчает проведение новых экспериментов без страха разрушить существующую функциональность и позволяет одновременно работать со множеством несвязанных функций. Кроме того, ветки облегчают ведение нескольких совместных рабочих процессов.
Использование: существующие ветки
В вышеприведенном примере показано, как просмотреть список доступных веток с помощью команды git branch и переключиться на конкретную ветку (в данном случае — на ветку feature_inprogress_branch ).
Новые ветки
Переключение веток
Переключение на удаленную ветку
При совместной работе команды нередко используют удаленные репозитории. Такие репозитории могут размещаться на сервере с предоставлением общего доступа либо это может быть локальная копия другого коллеги. Каждый удаленный репозиторий содержит собственный набор веток. Для переключения на удаленную ветку нужно сначала извлечь содержимое этой ветки.
В современных версиях Git переключение на удаленную ветку не отличается от переключения на локальную ветку.
В старых версиях Git необходимо создавать новую ветку на основе удаленного репозитория ( remote ).
Кроме того, можно переключиться на новую локальную ветку и сбросить ее до последнего коммита удаленной ветки.
Открепленные указатели HEAD
Резюме
Готовы попробовать ветвление?
Ознакомьтесь с этим интерактивным обучающим руководством.
Основы ветвления и слияния
Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:
Вы работаете над сайтом.
Вы создаете ветку для новой статьи, которую вы пишете.
Вы работаете в этой ветке.
В этот момент вы получаете сообщение, что обнаружена критическая ошибка, требующая скорейшего исправления. Ваши действия:
Переключиться на основную ветку.
Создать ветку для добавления исправления.
После тестирования слить ветку содержащую исправление с основной веткой.
Переключиться назад в ту ветку, где вы пишете статью и продолжить работать.
Основы ветвления
Предположим, вы работаете над проектом и уже имеете несколько коммитов.
Это то же самое что и:
Вы работаете над своим сайтом и делаете коммиты. Это приводит к тому, что ветка iss53 движется вперед, так как вы переключились на нее ранее ( HEAD указывает на нее).
Но перед тем как сделать это — имейте в виду, что если рабочий каталог либо индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master :
С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над проблемой #53, и вы можете сосредоточиться на работе над исправлением. Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последнего коммита в эту ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда был сделан последний коммит.
Теперь вы можете перейти к написанию исправления. Давайте создадим новую ветку для исправления, в которой будем работать, пока не закончим исправление.
Вы можете прогнать тесты, чтобы убедиться, что ваше исправление делает именно то, что нужно. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge :
Теперь вы можете переключиться обратно на ветку iss53 и продолжить работу над проблемой #53:
Основы слияния
Вместо того, чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый результирующий снимок трёхстороннего слияния, а затем автоматически делает коммит. Этот особый коммит называют коммитом слияния, так как у него более одного предка.
Теперь, когда изменения слиты, ветка iss53 больше не нужна. Вы можете закрыть задачу в системе отслеживания ошибок и удалить ветку:
Основные конфликты слияния
Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока вы не разрешите конфликт. Чтобы в любой момент после появления конфликта увидеть, какие файлы не объединены, вы можете запустить git status :
Всё, где есть неразрешённые конфликты слияния, перечисляется как неслитое. В конфликтующие файлы Git добавляет специальные маркеры конфликтов, чтобы вы могли исправить их вручную. В вашем файле появился раздел, выглядящий примерно так:
Мы рассмотрим более продвинутые инструменты для разрешения сложных конфликтов слияния в разделе Продвинутое слияние главы 7.
Если это вас устраивает и вы убедились, что все файлы, где были конфликты, добавлены в индекс — выполните команду git commit для создания коммита слияния. Комментарий к коммиту слияния по умолчанию выглядит примерно так:
Если вы считаете, что коммит слияния требует дополнительных пояснений — опишите как были разрешены конфликты и почему были применены именно такие изменения, если это не очевидно.
rdnvndr / MainGit.md
Основы работы с Git
Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.
Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.
Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.
Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.
Основы работы с удаленным репозиторием
git clone — создание копии (удаленного) репозитория
Для начала работы с центральным репозиторием, следует создать копию оригинального проекта со всей его историей локально.
Клонирует репозиторий, используя протокол http:
Клонирует репозиторий с той же машины в директорию myrepo:
Клонирует репозиторий, используя безопасный протокол ssh:
У git имеется и собственный протокол:
Импортирует svn репозиторий, используя протокол http:
git fetch и git pull — забираем изменения из центрального репозитория
Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.
git fetch — забирает изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.
Получает изменений из определенного репозитория:
Возможно также использовать синонимы для адресов, создаваемые командой git remote:
Естественно, что после оценки изменений, например, командой git diff, надо создать коммит слияния с основной:
Команда git pull сразу забирает изменения и проводит слияние с активной веткой. Забирает из репозитория, для которого были созданы удаленные ветки по умолчанию:
Забирает изменения и метки из определенного репозитория:
Как правило, используется сразу команда git pull.
git push — вносим изменения в удаленный репозиторий
После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.
Отправляет свои изменения в удаленную ветку, созданную при клонировании по умолчанию:
Отправляет изменения из ветки master в ветку experimental удаленного репозитория:
В удаленном репозитории origin удаляет ветку experimental:
Отправляет в удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:
Отправляет метки в удаленную ветку master репозитория origin:
Изменяет указатель для удаленной ветке master репозитория origin (master будет такой же как и develop):
Добавляет ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:
Работа с локальным репозиторием
git init — создание репозитория
git add и git rm — индексация изменений
Следующее, что нужно знать — команда git add. Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит.
Индексирует измененный файл, либо оповещение о создании нового:
Вносит в индекс все изменения, включая новые файлы:
Из индекса и дерева проекта одновременно файл можно удалить командой git rm.
Удаляет из индекса и дерева проекта отдельные файлы:
Хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:
Вносит в индекс все удаленные файлы:
Сбросить весь индекс или удалить из него изменения определенного файла можно командой git reset:
Удаляет из индекса конкретный файл:
Команда git reset используется не только для сбрасывания индекса, поэтому дальше ей будет уделено гораздо больше внимания.
git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы
Команду git status, пожалуй, можно считать самой часто используемой наряду с командами коммита и индексации. Она выводит информацию обо всех изменениях, внесенных в дерево директорий проекта по сравнению с последним коммитом рабочей ветки; отдельно выводятся внесенные в индекс и неиндексированные файлы. Использовать ее крайне просто:
Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.
git commit — совершение коммита
Коммит — базовое понятие во всех системах контроля версий, поэтому совершаться он должен легко и по возможности быстро. В простейшем случае достаточно после индексации набрать:
Если индекс не пустой, то на его основе будет совершен коммит, после чего пользователя попросят прокомментировать вносимые изменения вызовом команды edit. Сохраняемся, и вуаля! Коммит готов. Есть несколько ключей, упрощающих работу с git commit.
Совершает коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено:
Комментирует коммит прямо из командной строки вместо текстового редактора:
Вносит в индекс и создаёт коммит на основе изменений единственного файла:
Пример написания хорошего сообщения коммита:
git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»
Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).
Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.
Естественно, можно вернуться и на большую глубину коммитов,
Если команда достигнет точки ветвления, удаления коммита не произойдет.
Для команд слияния или выкачивания последних изменений с удаленного репозитория примеры резета будут приведены в соответствующих разделах.
git revert — отмена изменений, произведенных в прошлом отдельным коммитом
Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.
Отменяет коммит, помеченный тегом:
Отменяет коммит, используя его хэш:
Для отмены коммита слияния (коммита у которого несколько родителей), необходимо указать хэш и номер одного из родителей коммита:
Для использования команды необходимо, чтобы состояние проекта не отличалось от состояния, зафиксированного последним коммитом.
git log — разнообразная информация о коммитах в целом
Иногда требуется получить информацию об истории коммитов; коммитах, изменивших отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих целей используется команда git log.
Простейший пример использования, в котором приводится короткая справка по всем коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении подробно узнать можно ниже, в разделе «Ветвления и слияния»):
Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра его имя (кстати, в моей старой версии git этот способ не срабатывает, обязательно добавлять » — » перед «README»):
или, если версия git не совсем свежая:
Далее приводится только более современный вариант синтаксиса. Возможно указывать время, начиная в определенного момента («weeks», «days», «hours», «s» и так далее):
изменения, касающиеся отдельной папки:
Можно отталкиваться от тегов.
Все коммиты, начиная с тега v1:
Все коммиты, включающие изменения файла README, начиная с тега v1:
Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:
Выводит на каждый из коммитов по строчке, состоящей из хэша (здесь — уникального идентификатора каждого коммита, подробней — дальше):
Лаконичная информация о коммитах, приводятся только автор и комментарий:
Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:
В принципе, формат вывода можно определить самостоятельно:
git diff — отличия между деревьями проекта, коммитами и т.д.
Показывает изменения, не внесенные в индекс:
Изменения, внесенные в индекс:
Изменения в проекте по сравнению с последним коммитом:
Можно сравнивать «головы» веток:
или активную ветку с какой-либо:
git show — показать изменения, внесенные отдельным коммитом
Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show:
git blame и git annotate — команды, помогающие отслеживать изменения файлов
При работе в команде часто требуется выяснить, кто именно написал конкретный код. Удобно использовать команду git blame, выводящую построчную информацию о последнем коммите, коснувшемся строки, имя автора и хэш коммита:
Можно указать и конкретные строки для отображения:
Аналогично работает команда git annotate, выводящая и строки, и информацию о коммитах, их коснувшихся:
git grep — поиск слов по проекту, состоянию проекта в прошлом
git grep, в целом, просто дублирует функционал знаменитой юниксовой команды. Однако он позволяет слова и их сочетания искать в прошлом проекта, что бывает очень полезно.
Ищет слова tst в проекте:
Подсчитывает число упоминаний tst в проекте:
Ищет в старой версии проекта:
Команда позволяет использовать логическое И и ИЛИ.
Ищет строки, где упоминаются и первое слово, и второе:
Ищет строки, где встречается хотя бы одно из слов:
git branch — создание, перечисление и удаление веток
Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде.
Просто перечисляет существующие ветки, отметив активную:
Создаёт новую ветку new-branch:
Удаляет ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:
Удаляет ветку в любом случае:
Показывывает те ветки, среди предков которых есть определенный коммит:
Показывает коммит ответвления ветки new-name-branch от ветки master:
git checkout — переключение между ветками, извлечение файлов
Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:
Создаёт ветку, в которую и произойдет переключение:
Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:
Возвращает somefile к состоянию последнего коммита:
Возвращает somefile к состоянию на два коммита назад по ветке:
git merge — слияние веток, разрешение возможных конфликтов
Слияние веток, в отличие от обычной практики централизованных систем, в git происходит практически каждый день. Естественно, что имеется удобный интерфейс к популярной операции.
Пытается объединить текующую ветку и ветку new-feature:
В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.
Например, конфликт возник в файле TROUBLE, что можно увидеть в git status.
Произошла неудачная попытка слияния:
Смотрим на проблемные места:
Индексируем наши изменения, тем самым снимая метки:
Совершаем коммит слияния:
Вот и все, ничего сложного. Если в процессе разрешения вы передумали разрешать конфликт, достаточно набрать (это вернёт обе ветки в исходные состояния):
Если же коммит слияния был совершен, используем команду:
git rebase — построение ровной линии коммитов
Предположим, разработчик завел дополнительную ветку для разработки отдельной возможности и совершил в ней несколько коммитов. Одновременно по какой-либо причине в основной ветке также были совершены коммиты: например, в нее были залиты изменения с удаленного сервера, либо сам разработчик совершал в ней коммиты.
В принципе, можно обойтись обычным git merge. Но тогда усложняется сама линия разработки, что бывает нежелательно в слишком больших проектах, где участвует множество разработчиков.
Предположим, имеется две ветки, master и топик, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.
Вариант, в котором явно указывается, что и куда накладывается:
на master накладывается активная в настоящий момент ветка:
После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования, разрешения конфликтов, файлы следует внести в индекс командой:
и продолжить наложение следующих коммитов командой:
Альтернативными выходами будут команды пропустить наложение коммита и перейти к следующему:
и отмена работы команды и всех внесенных изменений:
git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом
Если ведется сложная история разработки, с несколькими длинными ветками разработками, может возникнуть необходимость в применении изменений, внесенных отдельным коммитом одной ветки, к дереву другой (активной в настоящий момент).
Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:
Git позволяет работать одновременно с несколькими ветками одного репозитория. Для добавления ветки в отдельную директорию необходимо выполнить команду:
Для просмотра всех директориев с ветками можно воспользоваться командой:
Директорию с веткой можно перести в другое место с помощью команды:
После окончания работы с веткой в директории, её можно удалить командой:
Клонирование репозитория с подмодулями
При клонировании репозитория вам необходимо инициализировать и обновить подмодули:
Запуск данной команды эквивалентен запуску команды:
после обычного клонирования репозитория
Подмодуль ссылается на конкретную коммит в другом репозитории. Чтобы получить точное состояние всех подмодулей необходимо запустить:
Для получения состояния последнего коммита всех подмодулей необходимо выполнить следующую команду:
или использовать аргументы по умолчанию команды git pull:
Эта команда просто обновляет локальную рабочую копию. При запуске команды git status каталоги подмодулей будут показаны изменёнными. Чтобы обновить репозиторий необходимо зафиксировать изменения:
Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:
В текущий проект можно включить другой репозиторий Git в качестве папки, отслеживаемый Git:
Для перемещение подмодуля из одного места репозитория в другое место репозитория необходимо выполнить команду:
Для удаления подмодуля из репозитория необходимо удалить описание подмодуля и каталог с файлами подмодуля:
Прочие команды и необходимые возможности
Хэш — уникальная идентификация объектов
В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.
Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров использования хэшей в качестве способа адресации.
Ищет разницу текущего состояния проекта и коммита за номером… сами видите, каким:
То же самое, но оставляем только шесть первых символов. Git поймет, о каком коммите идет речь, если не существует другого коммита с таким началом хэша:
Иногда хватает и четырех символов:
Читает лог с коммита по коммит:
Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были введены другие объекты — тэги.
git tag — тэги как способ пометить уникальный коммит
Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.
Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.
Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:
Помечает определенный коммит:
Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:
После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff, git log и так далее:
Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».
Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария:
Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:
Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.
Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один механизм — относительную адресацию. Например, можно обратиться прямо к предку последнего коммита ветки master:
Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:
Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки.
Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки нужно погрузиться.
Что привнес «дедушка» нынешнего коммита:
Обозначения можно объединять, чтобы добраться до нужного коммита:
Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.
Пример содержимого такого файла:
Существуют и другие способы указания игнорируемых файлов, о которых можно узнать из справки git help gitignore.
Серверные команды репозитория
Проверяет сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория:
Переупаковывает локальный репозиторий:
Создание пустого репозитория на сервере
Импорт svn репозитория на Git-сервер
Связка локальной и удаленной ветки
Отправление ветки local в удаленный репозиторий и установка локальной ветки local отслеживаемой с origin/local:
Пометка локальной ветки как отслеживаемой с origin/local:
Создание новой пустой ветки
Создание пустой ветки с именем newbranch:
Использование Git для получения версии
Установка начала новой версии на текущий коммит:
Получение номера версии для последующие коммитов:
