Управление ветками
Теперь, когда вы уже попробовали создавать, объединять и удалять ветки, пора познакомиться с некоторыми инструментами для управления ветками, которые вам пригодятся, когда вы начнёте использовать ветки постоянно.
Команда git branch
делает несколько больше, чем просто создаёт и удаляет ветки.
При запуске без параметров, вы получите простой список имеющихся у вас веток:
$ git branch
iss53
* master
testing
Обратите внимание на символ *
, стоящий перед веткой master
: он указывает на ветку, на которой вы находитесь в настоящий момент (т. е. ветку, на которую указывает HEAD
).
Это означает, что если вы сейчас сделаете коммит, ветка master
переместится вперёд в соответствии с вашими последними изменениями.
Чтобы посмотреть последний коммит на каждой из веток, выполните команду git branch -v
:
$ git branch -v
iss53 93b412c Fix javascript issue
* master 7a98805 Merge branch 'iss53'
testing 782fd34 Add scott to the author list in the readme
Опции --merged
и --no-merged
могут отфильтровать этот список для вывода только тех веток, которые слиты или ещё не слиты в текущую ветку.
Чтобы посмотреть те ветки, которые вы уже слили с текущей, можете выполнить команду git branch --merged
:
$ git branch --merged
iss53
* master
Ветка iss53
присутствует в этом списке потому что вы ранее слили её в master
.
Те ветки из этого списка, перед которыми нет символа *
, можно смело удалять командой git branch -d
; наработки из этих веток уже включены в другую ветку, так что ничего не потеряется.
Чтобы увидеть все ветки, содержащие наработки, которые вы пока ещё не слили в текущую ветку, выполните команду git branch --no-merged
:
$ git branch --no-merged
testing
Вы увидите оставшуюся ветку.
Так как она содержит ещё не слитые наработки, попытка удалить её командой git branch -d
приведёт к ошибке:
$ git branch -d testing
error: The branch 'testing' is not fully merged.
If you are sure you want to delete it, run 'git branch -D testing'.
Если вы действительно хотите удалить ветку вместе со всеми наработками, используйте опцию -D
, как указано в подсказке.
Подсказка |
Если в качестве аргумента не указан коммит или ветка, то опции Вы всегда можете указать дополнительный аргумент для вывода той же информации, но относительно указанной ветки предварительно не извлекая и не переходя на неё.
|
Переименование ветки
Внимание |
Не переименовывайте ветки, которые всё ещё используются другими участниками. |
Предположим, у вас есть ветка с именем bad-branch-name
, и вы хотите изменить её на corrected-branch-name
, сохранив при этом всю историю.
Вместе с этим, вы также хотите изменить имя ветки на удалённом сервере (GitHub, GitLab или другой сервер).
Как это сделать?
Переименуйте ветку локально с помощью команды git branch --move
:
$ git branch --move bad-branch-name corrected-branch-name
Ветка bad-branch-name
будет переименована в corrected-branch-name
, но это изменение пока только локальное.
Чтобы все остальные увидели исправленную ветку в удалённом репозитории, отправьте её туда:
$ git push --set-upstream origin corrected-branch-name
Теперь проверим, где мы сейчас находимся:
$ git branch --all
* corrected-branch-name
main
remotes/origin/bad-branch-name
remotes/origin/corrected-branch-name
remotes/origin/main
Обратите внимание, что текущая ветка corrected-branch-name
, которая также присутствует и на удалённом сервере.
Однако, старая ветка всё ещё по-прежнему там, но её можно удалить с помощью команды:
$ git push origin --delete bad-branch-name
Теперь старое имя ветки полностью заменено исправленным.
Изменение имени главной ветки
Предупреждение |
Изменение имени ветки, например master/main/mainline/default, сломает интеграции, службы, вспомогательные утилиты и скрипты сборки, которые использует ваш репозиторий. |
Переименуйте локальную ветку master
в main
с помощью следующей команды:
$ git branch --move master main
После этого, локальной ветки master
больше не существует, потому что она была переименована в ветку main
.
Чтобы все остальные могли видеть новую ветку main
, вам нужно отправить её в общий репозиторий.
Это делает переименованную ветку доступной в удалённом репозитории.
$ git push --set-upstream origin main
В итоге, состояние репозитория становится следующим:
$ git branch --all
* main
remotes/origin/HEAD -> origin/master
remotes/origin/main
remotes/origin/master
Ваша локальная ветка master
исчезла, так как она заменена веткой main
.
Ветка main
доступна в удалённом репозитории.
Старая ветка master
всё ещё присутствует в удалённом репозитории.
Остальные участники будут продолжать использовать ветку master
в качестве основы для своей работы, пока вы не совершите ряд дополнительных действий.
Теперь, для завершения перехода на новую ветку перед вами стоят следующие задачи:
-
Все проекты, которые зависят от текущего, должны будут обновить свой код и/или конфигурацию.
-
Обновите конфигурацию всех запускаемых тестов.
-
Исправьте скрипты сборки и публикации артефактов.
-
Поправьте настройки репозитория на сервере: задайте новую ветку по умолчанию, обновите правила слияния, а также прочие настройки, которые зависят от имени веток.
-
Обновите документацию, исправив ссылки, указывающие на старую ветку.
-
Слейте или отмените запросы на слияние изменений, нацеленные на старую ветку.
После того, как вы выполнили все эти задачи и уверены, что ветка main
работает так же, как ветка master
, вы можете удалить ветку master
:
$ git push origin --delete master
NAME
git-switch — Switch branches
SYNOPSIS
git switch [<options>] [--no-guess] <branch> git switch [<options>] --detach [<start-point>] git switch [<options>] (-c|-C) <new-branch> [<start-point>] git switch [<options>] --orphan <new-branch>
DESCRIPTION
Switch to a specified branch. The working tree and the index are
updated to match the branch. All new commits will be added to the tip
of this branch.
Optionally a new branch could be created with either -c
, -C
,
automatically from a remote branch of same name (see --guess
), or
detach the working tree from any branch with --detach
, along with
switching.
Switching branches does not require a clean index and working tree
(i.e. no differences compared to HEAD
). The operation is aborted
however if the operation leads to loss of local changes, unless told
otherwise with --discard-changes
or --merge
.
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
OPTIONS
- <branch>
-
Branch to switch to.
- <new-branch>
-
Name for the new branch.
- <start-point>
-
The starting point for the new branch. Specifying a
<start-point>
allows you to create a branch based on some
other point in history than where HEAD currently points. (Or,
in the case of--detach
, allows you to inspect and detach
from some other point.)You can use the
@{-N}
syntax to refer to the N-th last
branch/commit switched to using «git switch» or «git checkout»
operation. You may also specify-
which is synonymous to@{-1}
.
This is often used to switch quickly between two branches, or to undo
a branch switch by mistake.As a special case, you may use
A...B
as a shortcut for the merge
base ofA
andB
if there is exactly one merge base. You can leave
out at most one ofA
andB
, in which case it defaults toHEAD
. - -c <new-branch>
- —create <new-branch>
-
Create a new branch named
<new-branch>
starting at
<start-point>
before switching to the branch. This is a
convenient shortcut for:$ git branch <new-branch> $ git switch <new-branch>
- -C <new-branch>
- —force-create <new-branch>
-
Similar to
--create
except that if<new-branch>
already
exists, it will be reset to<start-point>
. This is a
convenient shortcut for:$ git branch -f <new-branch> $ git switch <new-branch>
- -d
- —detach
-
Switch to a commit for inspection and discardable
experiments. See the «DETACHED HEAD» section in
git-checkout[1] for details. - —guess
- —no-guess
-
If
<branch>
is not found but there does exist a tracking
branch in exactly one remote (call it<remote>
) with a
matching name, treat as equivalent to$ git switch -c <branch> --track <remote>/<branch>
If the branch exists in multiple remotes and one of them is named by
thecheckout.defaultRemote
configuration variable, we’ll use that
one for the purposes of disambiguation, even if the<branch>
isn’t
unique across all remotes. Set it to e.g.checkout.defaultRemote=origin
to always checkout remote branches from there if<branch>
is
ambiguous but exists on the origin remote. See also
checkout.defaultRemote
in git-config[1].--guess
is the default behavior. Use--no-guess
to disable it.The default behavior can be set via the
checkout.guess
configuration
variable. - -f
- —force
-
An alias for
--discard-changes
. - —discard-changes
-
Proceed even if the index or the working tree differs from
HEAD
. Both the index and working tree are restored to match
the switching target. If--recurse-submodules
is specified,
submodule content is also restored to match the switching
target. This is used to throw away local changes. - -m
- —merge
-
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 withgit add
(orgit rm
if the merge
should result in deletion of the path). - —conflict=<style>
-
The same as
--merge
option above, but changes the way the
conflicting hunks are presented, overriding the
merge.conflictStyle
configuration variable. Possible values are
«merge» (default), «diff3», and «zdiff3». - -q
- —quiet
-
Quiet, suppress feedback messages.
- —progress
- —no-progress
-
Progress status is reported on the standard error stream
by default when it is attached to a terminal, unless--quiet
is specified. This flag enables progress reporting even if not
attached to a terminal, regardless of--quiet
. - -t
- —track [direct|inherit]
-
When creating a new branch, set up «upstream» configuration.
-c
is implied. See--track
in git-branch[1] for
details.If no
-c
option is given, the name of the new branch will be derived
from the remote-tracking branch, by looking at the local part of the
refspec configured for the corresponding remote, and then stripping
the initial part up to the «*». This would tell us to usehack
as
the local branch when branching off oforigin/hack
(or
remotes/origin/hack
, or evenrefs/remotes/origin/hack
). If the
given name has no slash, or the above guessing results in an empty
name, the guessing is aborted. You can explicitly give a name with
-c
in such a case. - —no-track
-
Do not set up «upstream» configuration, even if the
branch.autoSetupMerge
configuration variable is true. - —orphan <new-branch>
-
Create a new orphan branch, named
<new-branch>
. All
tracked files are removed. - —ignore-other-worktrees
-
git switch
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. - —recurse-submodules
- —no-recurse-submodules
-
Using
--recurse-submodules
will update the content of all
active submodules according to the commit recorded in the
superproject. If nothing (or--no-recurse-submodules
) is
used, submodules working trees will not be updated. Just
like git-submodule[1], this will detachHEAD
of the
submodules.
EXAMPLES
The following command switches to the «master» branch:
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
switch would fail like this:
$ git switch mytopic error: You have local changes to 'frotz'; not switching branches.
You can give the -m
flag to the command, which would try a three-way
merge:
$ git switch -m mytopic Auto-merging frotz
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.
To switch back to the previous branch before we switched to mytopic
(i.e. «master» branch):
You can grow a new branch from any commit. For example, switch to
«HEAD~3» and create branch «fixup»:
$ git switch -c fixup HEAD~3 Switched to a new branch 'fixup'
If you want to start a new branch from a remote branch of the same
name:
$ git switch new-topic Branch 'new-topic' set up to track remote branch 'new-topic' from 'origin' Switched to a new branch 'new-topic'
To check out commit HEAD~3
for temporary inspection or experiment
without creating a new branch:
$ git switch --detach HEAD~3 HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'
If it turns out whatever you have done is worth keeping, you can
always create a new name for it (without switching away):
$ git switch -c good-surprises
CONFIGURATION
Everything below this line in this section is selectively included
from the git-config[1] documentation. The content is the same
as what’s found there:
- checkout.defaultRemote
-
When you run
git checkout <something>
orgit switch <something>
and only have one
remote, it may implicitly fall back on checking out and
tracking e.g.origin/<something>
. This stops working as soon
as you have more than one remote with a<something>
reference. This setting allows for setting the name of a
preferred remote that should always win when it comes to
disambiguation. The typical use-case is to set this to
origin
.Currently this is used by git-switch[1] and
git-checkout[1] whengit checkout <something>
orgit switch <something>
will checkout the<something>
branch on another remote,
and by git-worktree[1] whengit worktree add
refers to a
remote branch. This setting might be used for other checkout-like
commands or functionality in the future. - checkout.guess
-
Provides the default value for the
--guess
or--no-guess
option ingit checkout
andgit switch
. See
git-switch[1] and git-checkout[1]. - checkout.workers
-
The number of parallel workers to use when updating the working tree.
The default is one, i.e. sequential execution. If set to a value less
than one, Git will use as many workers as the number of logical cores
available. This setting andcheckout.thresholdForParallelism
affect
all commands that perform checkout. E.g. checkout, clone, reset,
sparse-checkout, etc.Note: parallel checkout usually delivers better performance for repositories
located on SSDs or over NFS. For repositories on spinning disks and/or machines
with a small number of cores, the default sequential checkout often performs
better. The size and compression level of a repository might also influence how
well the parallel version performs. - checkout.thresholdForParallelism
-
When running parallel checkout with a small number of files, the cost
of subprocess spawning and inter-process communication might outweigh
the parallelization gains. This setting allows to define the minimum
number of files for which parallel checkout should be attempted. The
default is 100.
SEE ALSO
About renaming branches
You can rename a branch in a repository on GitHub.com. For more information about branches, see «About branches).»
When you rename a branch on GitHub.com, any URLs that contain the old branch name are automatically redirected to the equivalent URL for the renamed branch. Branch protection policies are also updated, as well as the base branch for open pull requests (including those for forks) and draft releases. After the rename is complete, GitHub provides instructions on the repository’s home page directing contributors to update their local Git environments.
Although file URLs are automatically redirected, raw file URLs are not redirected. Also, GitHub does not perform any redirects if users perform a git pull
for the previous branch name.
GitHub Actions workflows do not follow renames, so if your repository publishes an action, anyone using that action with @{old-branch-name}
will break. You should consider adding a new branch with the original content plus an additional commit reporting that the branch name is deprecated and suggesting that users migrate to the new branch name.
Renaming a branch
- On GitHub.com, navigate to the main page of the repository.
- Above the list of files, click Branches.
- In the list of branches, to the right of the branch you want to rename, click .
- Type a new name for the branch.
- Review the information about local environments, then click Rename branch.
Updating a local clone after a branch name changes
After you rename a branch in a repository on GitHub, any collaborator with a local clone of the repository will need to update the clone.
From the local clone of the repository on a computer, run the following commands to update the name of the default branch.
$ git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
$ git fetch origin
$ git branch -u origin/NEW-BRANCH-NAME NEW-BRANCH-NAME
$ git remote set-head origin -a
Optionally, run the following command to remove tracking references to the old branch name.
$ git remote prune origin
Перевод статьи «Git Switch Branch – How to Change the Branch in Git».
Пользуясь Git, вам очень часто придется перемещаться по веткам. Для этого используется команда git checkout.
Как создать новую ветку в Git и перейти в нее
Чтобы создать новую ветку, нужно использовать команду git checkout
с флагом -b
и указанием имени ветки. Таким образом вы создадите ответвление той ветки, в которой находитесь. История новой ветки начнется с момента ответвления.
Допустим, вы находитесь в ветке master
:
(master)$ git checkout -b my-feature Switched to a new branch 'my-feature' (my-feature)$
Вы видите, что была создана новая ветка с именем my-feature
. Она является ответвлением master
. После создания новой ветки вы автоматически перешли в нее.
Как перейти в уже существующую ветку в Git
Чтобы перейти в уже существующую ветку, используйте ту же команду git checkout
, но без добавления флага -b
. Команде нужно передать имя ветки, в которую вы хотите перейти:
(my-feature)$ git checkout master Switched to branch 'master' (master)$
Для перехода в предыдущую ветку (т. е. ту, из которой вы перешли в текущую) можно передать команде git checkout
не имя ветки, а просто дефис:
(my-feature)$ git checkout - Switched to branch 'master' (master)$ git checkout - Switched to branch 'my-feature' (my-feature)$
Как переместиться к определенному коммиту
Чтобы перейти к определенному коммиту, используйте ту же команду git checkout
, но вместо имени ветки передайте ей SHA коммита.
Ветки по сути являются просто указателями трекерами отдельных коммитов в истории Git.
Как найти SHA коммита
Один из способов найти SHA коммита — просмотреть лог Git. Делается это при помощи команды git log
:
(my-feature)$ git log commit 94ab1fe28727b7f8b683a0084e00a9ec808d6d39 (HEAD -> my-feature, master) Author: John Mosesman <johnmosesman@gmail.com> Date: Mon Apr 12 10:31:11 2021 -0500 This is the second commmit message. commit 035a128d2e66eb9fe3032036b3415e60c728f692 (blah) Author: John Mosesman <johnmosesman@gmail.com> Date: Mon Apr 12 10:31:05 2021 -0500 This is the first commmit message.
В первой строке каждого коммита после слова commit
есть длинная строка букв и цифр: 94ab1fe28727…
Вот она и называется SHA. Это уникальный идентификатор, генерируемый для каждого коммита.
Чтобы перейти к определенному коммиту, вам нужно лишь передать его SHA в качестве параметра команды git checkout
:
(my-feature)$ git checkout 035a128d2e66eb9fe3032036b3415e60c728f692 Note: switching to '035a128d2e66eb9fe3032036b3415e60c728f692'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c <new-branch-name> Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at 035a128 a ((HEAD detached at 035a128))$
Примечание: обычно можно использовать всего несколько первых символов SHA, потому что первые 4-5 символов скорее всего образуют уникальную комбинацию в рамках проекта.
Что такое detached HEAD (отсоединенный указатель HEAD)?
В результате перехода к конкретному коммиту вы указываетесь в «состоянии отсоединенного указателя HEAD» («detached HEAD state
»).
Из документации:
[a detached HEAD state] означает, что HEAD направлен на конкретный коммит, а не на именованную ветку.
В общем, HEAD (один из внутренних указателей Git, отслеживающий, где именно в истории Git вы находитесь) отклонился от известных веток, так что все изменения с этого момента будут формировать новый путь в истории Git. Поэтому Git хочет убедиться, что вы именно этого хотите, и в выводе предлагает вам пространство для экспериментов:
«Вы в состоянии detached HEAD. Можете осмотреться, внести какие-нибудь экспериментальные изменения и закоммитить их. Если затем вы переключитесь обратно на ветку, вы сбросите все коммиты, сделанные в этом состоянии, никак не задев никакие ветки».
Исходя из этого, у вас есть два варианта:
- поэкспериментировать, а затем сбросить все изменения, вернувшись в предыдущую ветку
- продолжить работу с этого места и начать новую ветку из этой точки.
Для возвращения в предыдущую ветку (со сбросом всех изменений) используйте команду git switch -
.
Если вы все же хотите сохранить свои изменения, внесенные в состоянии detached HEAD, и продолжить работу с этого места, можете использовать git switch -c <имя-новой-ветки>
, чтобы создать новую ветку из этой точки.
Заключение
Команда git checkout
— очень полезная и многофункциональная. С ее помощью можно создавать новые ветки, перемещаться по веткам и коммитам и т. д.
Окт 09, 2021
Olha L.
3хв. читання
Если вы работаете в Git, то вам, наверняка, знакома ситуация, когда ветка случайно была названа неправильно или просто нужно сменить её название, чтобы лучше организовать проект. В любом случае это довольно распространённое явление, когда вам нужно переименовать ветку Git, локальную или удалённую. В этом руководстве мы покажем, как это сделать. А также кратко объясним, что такое Git-репозиторий и некоторые полезные команды Git.
Установите и используйте Git вместе с мощным и надёжным хостингом от Hostinger.
Как Переименовать Локальную Ветку Git?
Прежде чем мы начнём, убедитесь, что вы выбрали ветку, которую хотите переименовать:
git checkout staroje-imia
Если вы хотите посмотреть все локальные ветки, используйте следующую команду:
git branch --list
Разобравшись с этим, выполните следующее действие:
- Чтобы переименовать текущую ветку Git, добавьте к команде опцию -m:
git branch -m novoje-imia
- Вы также можете переименовать локальную ветку, находясь на другой ветке, используя следующие две команды:
git checkout master git branch -m staroje-imia novoje-imia
- Наконец, эта команда выведет список всех, как локальных, так и удалённых веток. Убедитесь, что ветка с новым названием есть в этом списке.
git branch -a
Как Переименовать Удалённую Ветку Git?
Хотя удалённую ветку и нельзя переименовать напрямую, процесс довольно простой и состоит лишь с трёх шагов:
- Для начала вам нужно будет переименовать локальную ветку, следуя инструкции выше.
- Затем удалите старую ветку и запуште новую. Сделать это можно с помощью следующих простых команд:
git push origin --delete staroje-imia git push origin :staroje-imia novoje-imia
- Выгрузите новую ветку и «закрепите» её за локальной:
git push origin -u novoje-imia
Как Создать Новую Локальную Ветку Git?
Прежде чем создавать новую ветку, обратите внимание, что каждый репозиторий, о котором мы будем говорить дальше, содержит основную стабильную ветку (master branch), содержащую изменения, готовые для продакшена. Когда вы создаёте ветку, всё, что делает Git, это создаёт новый указатель.
Мы можем создать новую локальную ветку, выполнив следующие шаги.
- Перейдите в корень вашей master branch:
cd nazvanije-repozitorija
- Вы можете создать ветку из главной ветки с помощью следующей команды:
git branch imia-novoj-vetki
Или же вы можете создать новую ветку и переключиться на неё:
git checkout -b imia-novoj-vetki
Вы также можете клонировать ветку и затем перейти на неё:
git checkout -b imia-novoj-vetki origin/imia-novoj-vetki
- Переключитесь на новую ветку:
git checkout imia-novoj-vetki
- Наконец, убедитесь, что вы находитесь в новой ветке:
git status
Как Удалить Локальную Ветку Git?
Чтобы удалить локальную ветку, вы можете использовать одну из следующих команд Git:
git branch -d imia-vetki git branch -D imia-vetki
Опция -d (–delete) удалит локальную ветку, если вы уже запушили и смержили её с удалённой веткой.
Опция -D (–delete –force) удалит локальную ветку независимо от того, успели вы запушить и смержить её с удалённой веткой или нет.
Как Удалить Удалённую Ветку Git?
Вы также можете удалить удалённую ветку и указать, как название удалённого репозитория, так и ветки. В большинстве случаев, название удалённого сервера по умолчанию — «origin«. Команда будет выглядеть так:
git push imia_udalennogo_repozitorija --delete imia-vetki git push imia_udalennogo_repozitorija :imia-vetki
Осмотр и Сравнение
В Git вы можете просмотреть все внесённые вами изменения в любое время. Чтобы увидеть эти изменения, введите следующую команду:
git log
Или, для более подробной информации:
git log --summary
Что Такое Ветка Git?
Git — это распределённая система контроля версий (DVCS), в которой все члены команды имеют доступ к полной версии проекта. Её главная задача — помогать в управлении проектам, сделать процесс разработки эффективным, гибким и безопасным.
Ветки — это отдельные линии развития вашего проекта. Они позволяют работать параллельно с master веткой, при этом не влияя на неё. Когда же ваша часть кода готова, вы можете выполнить слияние, или мерж.
Ветвление Git позволяет создавать, удалять и смотреть другие ветки. Кроме того, ветка действует как указатель на моментальный снимок изменений (snapshot), которые вы внесли или хотите внести в файлы проекта. Это полезно в ситуациях, когда вы хотите добавить дополнительную функцию или устранить баг.
Ветка не только инкапсулирует изменения, но также гарантирует, что нестабильный код не попадёт к файлам основного проекта. Как только вы закончите обновлять код в ветке, вы сможете смержить изменения в ветку master.
Что Такое Git-репозиторий?
Репозиторий работает как папка для проекта. Он содержит все файлы и хранит их историю изменений. Репозитории могут быть частными или общедоступными. Вы также можете делиться ими с другими людьми в вашей организации.
Когда вы инициализируете Git-репозиторий, в корне папки проекта автоматически создаётся каталог .git/. Здесь Git отслеживает изменения в файлах проекта, сохраняет объекты, ссылки и дополнительную информацию для управления репозиториями.
Будьте осторожны, ведь если вы случайно удалите папку .git/, вы потеряете всю истерию вашего проекта.
Как Клонировать Удалённый Репозиторий?
Чтобы клонировать репозиторий, мы будем использовать команду Git clone. Кроме того, вам также необходимо указать URL-адрес репозитория:
- Вы можете клонировать главную ветку (master branch) из удалённого репозитория с помощью HTTPS или SSH.
Для HTTPS:git clone https://github.com/imia-polzovatelia/imia-vashego-repozitorija.git
Для SSH:
git clone ssh://github.com/imia-polzovatelia/imia-vashego-repozitorija.git
- Чтобы перейти в корень клонированного репозитория, вы можете использовать команду cd:
cd vashi_prilozhenija
- Проверить состояние ветки можно с помощью простой команды Git:
git status
Дополнительная Информация о Git
Если вам нужна информация о том, как пользоваться Git, обратитесь к официальной документации, доступной онлайн. Кроме того, рекомендуем ознакомиться с нашими руководствами об основных командах Git, о том, как использовать PuTTY SSH-терминал для подключения к вашей учётной записи хостинга или VPS-серверу, как установить Git (англ) в Ubuntu, а также подробное руководство по GitHub.
Итоги
Теперь вы знаете, как управлять ветками с помощью различных команд. Вы можете создать или переименовать ветку Git, посмотреть список существующих веток или удалить какую-то из них.
Мы надеемся, что вам понравилось это руководство. И с нетерпением ждём вас в следующем!
Ольга вже близько восьми років працює менеджером у сфері IT, три з яких вона займається SEO. Написання технічних завдань та інструкцій — один з її основних обов’язків. Її хобі — дізнаватися щось нове і створювати цікаві та корисні статті про сучасні технології, веброзробку, мови програмування, пошукову оптимізацію сайтів та багато іншого.
Создал я ветку, например, mycode. Затем внёс необходимые изменения, сделал commit, push. Теперь подумал, что буду делать ещё несколько похожих веток с похожим функционалом и переименую первую в api_mycode. Это можно как-то сделать?
mymedia
8,4434 золотых знака28 серебряных знаков52 бронзовых знака
задан 10 авг 2017 в 7:32
2
Для переименования ветки, загруженной на удалённый сервер, нужно вначале переименовать ветку локально, а затем выгрузить изменения обратно, удалив предыдущую ветку на сервере.
git branch -m старое_название новое_название
git push origin :старое_название новое_название
Во второй строчке обратите внимание на двоеточие перед старым именем ветки — это команда для удаления ветки на сервере.
ответ дан 10 авг 2017 в 8:08
mymediamymedia
8,4434 золотых знака28 серебряных знаков52 бронзовых знака
5
Не нашел подтверждения о сохранении «истории ветки».
Поэтому пишу этот ответ где разобрался используя документацию Git
Внимание
- Не переименовывайте ветки, которые всё ещё используются другими участниками.
- Не переименовывайте ветку в master/main/mainline, не читая инструкцию по измени названия главной ветки.
Теперь к смене имени ветки
$ git branch --move bad-branch-name corrected-branch-name
или
$ git branch -m bad-branch-name corrected-branch-name
Таким образом мы сменим название ветки только локально
Отправим изменения на удаленный репозиторий
$ git push --set-upstream origin corrected-branch-name
Проверить изменения можно командой
$ git branch --all
Там будут выведен список веток локального и удаленного репозитория
* текущая ветка
другие локальные ветки
remotes/origin/текущие удаленные ветки
На текущий момент у нас останется старая ветка на удаленном репозитории. Можно удостовериться, что история перешла в новую ветку. Удалить старую ветку можно командой
$ git push origin --delete bad-branch-name
Так мы полностью заменим старое имя ветки на новое.
ответ дан 21 ноя 2022 в 14:51
2
Проще всего переименовать прямо на GitHub, там есть такая кнопка.
Но локально все равно придётся тоже переименовать и обновить связи.
Причем всем коллегам.
git branch -m bad-branch-name corrected-branch-name
git fetch origin
git branch -u origin/corrected-branch-name corrected-branch-name
git remote set-head origin -a
ответ дан 30 янв в 4:32
Чтобы исправить баг или сделать новую фитчу в проекте, обычно создают новую ветку. Зачем? Чтобы избежать путаницы. Если бы все делалось в основной ветке, в проекте было бы сложно разобраться, особенно если над ним одновременно работает много людей.
Поэтому только по окончании работы над задачей изменения в ветке сливают в основную ветку master.
Создание ветки
Чтобы создать новую ветку testing локально, выполним команду:
$ git branch testing
На момент выполнения команды вы находились в какой-то ветке, допустим в master. Состояние этой ветки будет скопировано в ветку testing, и в testing можно будет редактировать файлы и делать снимки, не трогая пока основную ветку master.
Переключение на ветку
Предыдущая команда создаст ветку, но не переключит нас на нее, мы все еще останемся работать в старой ветке. Чтобы перейти на ветку testing и начать работать в ней, выполним команду:
$ git checkout testing
Имейте в виду, что GIT не позволит перейти на другую ветку, если в текущей ветке — в которой мы находимся — есть изменения, которые не зафиксированы (commit) либо не спрятаны (stash). Это нормально, ведь при смене ветке в текущем каталоге сменятся файлы, и git-у надо знать, как быть с текущими изменениями.
Создание и переключение единой командой
Чтобы не выполнять предыдущие команды по очереди, можно написать их одной строкой:
$ git checkout –b testing
Эта команда создаст ветку testing и сразу переключит нас на нее. Обычно именно это и требуется сделать.
Как переключиться на чью-то ветку из удаленного репозитория
Важно понимать, что GIT не позволит вам работать над чужой веткой. Принцип такой — вы создаете локальную копию чужой ветки, и над ней уже работаете.
Но для начала надо обновить локальный репозиторий — скопировать в него все ветки, которые есть в удаленном репозитории:
git fetch
Теперь можно посмотреть, какие ветки есть в удаленном репозитории:
git branch -v -a
Допустим, там есть ветка dev1. Переключимся на нее, создав локальную ветку с таким же именем:
git checkout -b dev1 origin/dev1
Вообще-то можно было написать проще:
git checkout dev1
Но:
- Эта команда сработает только в том случае, если удаленный репозиторий у вас единственный. Если их два, например origin и upstream, то непонятно, на чью ветку переключаться.
- Она создаст локальную ветку с точно таким же именем dev1. А в полной версии можно было создать локальную ветку и с другим именем mydev1:
git checkout -b mydev1 origin/dev1
Как создать подветку ветки
Обычно мы ответвляемся от основной ветки master, но не всегда. Иногда требуется сделать ответвление от созданной ветки — так сказать, ответвление второго порядка.
Предыдущая команда, с помощью которой мы создавали ветку:
$ git branch testing
создает ответвление от основной ветки master.
Если нам надо ответвиться не от основной ветки, а от вновь созданной testing, то выполним поочередно команды:
$ git checkout testing $ git checkout -b subbranch_of_testing testing
Первая команда переключит нас на ветку testing.
Вторая команда создаст ветку с именем subbranch_of_testing, ответвляющуюся от testing, и переключит нас на нее.
Как понятно из имени, subbranch_of_testing – это подветка ветки testing.
Как посмотреть ветки
Чтобы увидеть все созданные локально ветки, выполним команду:
$ git branch
Появится список веток. Текущая ветка будет выделена звездочкой.
Как переименовать ветку
Иногда оказывается, что первоначально созданное имя ветки не самое лучшее. Его можно изменить.
Локальную
Если еще не выполнена команда push, то достаточно переименовать локальную ветку.
Чтобы переименовать локальную ветку, выполним команду:
$ git branch -m <old-name> <new-name>
Например, переименуем ветку testing в ветку test:
$ git branch –m testing test
Чтобы переименовать текущую ветку, выполним команду:
$ git branch -m <new-name>
Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:
$ git branch –m subbranch
Удаленную
Переименовать удаленную ветку (ветку в удаленном репозитории) нельзя. Можно удалить ее и отправить в репозиторий локальную ветку с новым именем:
$ git push origin :old-name new-name
здесь origin — имя удаленного репозитория (обычно удаленный репозиторий так называется),
old-name — имя ветки локальной ветки,
new-name — новое имя ветки в удаленном репозитории.
Например, надо переименовать ветку testing в test:
$ git push origin :testing test
Удаление локальной ветки
Чтобы удалить локальную ветку, выполните одну из команд:
$ git branch -d branch_name $ git branch -D branch_name
Флаги:
-D сокращение для —delete –force удаляет ветку независимо от того, слиты ли ее изменения
-d сокращение для —delete
Например, удалим локальную ветку test:
$ git branch –d test
Вообще-то локальную ветку обычно удаляют после того, как слили ее (выполнили merge) в ветку master, смотрите последний раздел в статье о слиянии веток.
Удаление ветки из удаленного репозитория
Чтобы удалить удаленную ветку, можно использовать две записи.
Либо через двоеточие, как мы уже делали при переименовании ветки:
$ git push origin :branch_name
Например, удалим ветку test из удаленного репозитория origin:
$ git push origin :test
Либо с флагом —delete, так понятнее:
$ git push origin --delete test
здесь origin — имя удаленного репозитория
Как слить ветки
Обычно сливают некоторую ветку (например, ветку-багфикс) в ветку master. Для этого сначала перейдем в ветку master (в ту ветку, в которую вливаем изменения):
$ git checkout master
А затем выполним слияние. Допустим, в ветку master надо слить ветку test :
$ git merge test
Слияние веток не всегда происходит гладко, иногда требуется разрешить конфликты вручную. Для этого надо отредактировать конфликтые файлы, выполнить их commit.
Итог
В этой статье мы рассмотрели работу с ветками GIT и составили небольшую шпаргалку по использованию веток.
На этой странице рассматривается команда git checkout
, включая примеры использования и пограничные случаи. В Git под термином checkout подразумевают переключение между различными версиями целевого объекта. Команда git checkout
работает с тремя различными объектами: файлами, коммитами и ветками. Под переключением также обычно понимают действие, связанное с выполнением команды git checkout
. В рамках темы «Отмена изменений» мы рассмотрели, каким образом команду git checkout
можно использовать для просмотра старых коммитов. В этом документе основное внимание будет уделено операциям переключения на ветки.
Переключение веток аналогично переключению старых коммитов и файлов, в которых рабочий каталог обновляется в соответствии с выбранной веткой/ревизией; вместе с тем новые изменения сохраняются в истории проекта, то есть это не просто операция чтения.
Переключение веток
Команда git checkout
позволяет перемещаться между ветками, созданными командой git branch
. При переключении ветки происходит обновление файлов в рабочем каталоге в соответствии с версией, хранящейся в этой ветке, а Git начинает записывать все новые коммиты в этой ветке. Рассматривайте эту команду как способ выбрать направление своей разработки.
Наличие выделенной ветки для каждой новой функции сильно отличается от традиционного рабочего процесса в SVN. Это значительно облегчает проведение новых экспериментов без страха разрушить существующую функциональность и позволяет одновременно работать со множеством несвязанных функций. Кроме того, ветки облегчают ведение нескольких совместных рабочих процессов.
Иногда команду git checkout
можно спутать с командой git clone
. Разница между этими двумя командами заключается в том, что при клонировании (clone) выполняется извлечение кода из удаленного репозитория, тогда как при переключении (checkout) происходит переключение между версиями кода, который уже находится в локальной системе.
Использование: существующие ветки
Если предположить, что ваш рабочий репозиторий уже содержит существующие ветки, вы можете переключаться между этими ветками с помощью команды git checkout
. Чтобы узнать, какие ветки доступны и как называется текущая ветка, выполните команду git branch
.
$> git branch
main
another_branch
feature_inprogress_branch
$> git checkout feature_inprogress_branch
В вышеприведенном примере показано, как просмотреть список доступных веток с помощью команды git branch
и переключиться на конкретную ветку (в данном случае — на ветку feature_inprogress_branch
).
Новые ветки
Команда git checkout
часто используется вместе с командой git branch
. С помощью команды git branch
можно создать новую ветку. Когда вы захотите начать работу над новой функцией, создайте новое ответвление от ветки main
с помощью команды git branch new_branch
. Затем переключитесь на новую ветку с помощью команды git checkout new_branch
. Команда git checkout
также принимает аргумент -b
, который действует как вспомогательный метод, позволяя создать новую ветку и сразу переключиться на нее. Вы можете работать сразу с несколькими функциями в одном репозитории, переключаясь между ними с помощью git checkout
.
git checkout -b <new-branch>
В вышеприведенном примере одновременно создается ветка <новая-ветка>
и сразу же выполняется переключение на нее. Опция -b
— это удобный способ сообщить системе Git, чтобы она выполнила команду git branch <новая-ветка>
перед выполнением команды git checkout <новая-ветка>
.
git checkout -b <new-branch> <existing-branch>
По умолчанию команда git checkout -b
создает ветку новая-ветка
от текущего указателя HEAD
. Команде git checkout
можно передать необязательный параметр с указанием ветки. В приведенном выше примере передается <
существующая-ветка>
, поэтому новая-ветка
будет создана от ветки существующая-ветка
, а не от текущего указателя HEAD
.
Переключение веток
Переключение веток — простая операция. При выполнении следующей команды указатель HEAD
будет перенесен на последний коммит ветки <название-ветки>
.
git checkout <branchname>
Git отслеживает историю операций переключения в журнале ссылок reflog. Чтобы просмотреть эту историю, выполните команду git reflog
.
Переключение на удаленную ветку
При совместной работе команды нередко используют удаленные репозитории. Такие репозитории могут размещаться на сервере с предоставлением общего доступа либо это может быть локальная копия другого коллеги. Каждый удаленный репозиторий содержит собственный набор веток. Для переключения на удаленную ветку нужно сначала извлечь содержимое этой ветки.
git fetch --all
В современных версиях Git переключение на удаленную ветку не отличается от переключения на локальную ветку.
git checkout <remotebranch>
В старых версиях Git необходимо создавать новую ветку на основе удаленного репозитория (remote
).
git checkout -b <remotebranch> origin/<remotebranch>
Кроме того, можно переключиться на новую локальную ветку и сбросить ее до последнего коммита удаленной ветки.
git checkout -b <branchname>
git reset --hard origin/<branchname>
Открепленные указатели HEAD
Теперь, когда мы рассмотрели три основных варианта использования команды git checkout
на ветках, важно обсудить состояние detached HEAD
, или состояние открепленного указателя HEAD. Помните, что HEAD
— это указатель на текущий снимок в Git. По сути дела, команда git checkout
просто обновляет указатель HEAD
, чтобы он ссылался на указанную ветку или коммит. Когда HEAD указывает на ветку, Git молчит, но при попытке переключиться на коммит система переходит в состояние detached HEAD
(открепленный указатель HEAD).
Это сообщение предупреждает о том, что вся текущая работа «откреплена» от остальной части вашего проекта. Если вы начнете разрабатывать функцию, находясь в состоянии открепленного указателя HEAD
, у вас не будет ветки, которая позволила бы вам вернуться к этой функции. Когда вы неизбежно переключитесь на другую ветку (например, чтобы слить код своей функции), вы уже никак не сможете сослаться на свою функцию:
Всегда ведите разработку на ветке, а не на открепленном указателе HEAD
. Это гарантия того, что у вас всегда будет ссылка на ваши новые коммиты. Вместе с тем при просмотре предыдущего коммита состояние указателя HEAD
не имеет значения: он может быть как откреплен, так и нет.
Резюме
Эта страница посвящена использованию команды git checkout
при смене веток. В общем и целом при использовании команды git checkout
на ветках происходит изменение ссылки в указателе HEAD
. Эту команду можно использовать для создания веток, переключения между ветками и удаленными ветками. Команда git checkout
— важный инструмент при стандартной работе в Git. Она представляет собой аналог команды git merge
. Команды git checkout
и git merge
— критически важные инструменты для реализации рабочих процессов Git
.