Git checkout unmerged error

-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.

-f

—force

When switching branches, proceed even if the index or the
working tree differs from HEAD, and even if there are untracked
files in the way. This is used to throw away local changes and
any untracked files or directories that are in the way.

When checking out paths from the index, do not fail upon unmerged
entries; instead, unmerged entries are ignored.

—ours

—theirs

When checking out paths from the index, check out stage #2
(ours) or #3 (theirs) for unmerged paths.

Note that during git rebase and git pull --rebase, ours and
theirs may appear swapped; --ours gives the version from the
branch the changes are rebased onto, while --theirs gives the
version from the branch that holds your work that is being rebased.

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»).

-b <new-branch>

Create a new branch named <new-branch> and start it at
<start-point>; see git-branch[1] for details.

-B <new-branch>

Creates the branch <new-branch> and start it at <start-point>;
if it already exists, then reset it to <start-point>. This is
equivalent to running «git branch» with «-f»; see
git-branch[1] for details.

-t

—track[=(direct|inherit)]

When creating a new branch, set up «upstream» configuration. See
«—track» in git-branch[1] for details.

If no -b 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 use hack as the local branch when branching
off of origin/hack (or remotes/origin/hack, or even
refs/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 -b in such a case.

—no-track

Do not set up «upstream» configuration, even if the
branch.autoSetupMerge configuration variable is true.

—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 checkout -b <branch> --track <remote>/<branch>

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 <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.

-l

Create the new branch’s reflog; see git-branch[1] for
details.

-d

—detach

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 <commit> when
<commit> is not a branch name. See the «DETACHED HEAD» section
below for details.

—orphan <new-branch>

Create a new orphan branch, named <new-branch>, started from
<start-point> and switch to it. The first commit made on this
new branch will have no parents and it will be the root of a new
history totally disconnected from all the other branches and
commits.

The index and the working tree are adjusted as if you had previously run
git checkout <start-point>. This allows you to start a new history
that records a set of paths similar to <start-point> by easily running
git commit -a to make the root commit.

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.

If you want to start a disconnected history that records a set of paths
that is totally different from the one of <start-point>, then you should
clear the index and the working tree right after creating the orphan
branch by running git rm -rf . from the top level of the working tree.
Afterwards you will be ready to prepare your new files, repopulating the
working tree, by copying them from elsewhere, extracting a tarball, etc.

—ignore-skip-worktree-bits

In sparse checkout mode, git checkout -- <paths> would
update only entries matched by <paths> and sparse patterns
in $GIT_DIR/info/sparse-checkout. This option ignores
the sparse patterns and adds back any files in <paths>.

-m

—merge

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.

When switching branches with --merge, staged changes may be lost.

—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».

-p

—patch

Interactively select hunks in the difference between the
<tree-ish> (or the index, if unspecified) and the working
tree. The chosen hunks are then applied in reverse to the
working tree (and if a <tree-ish> was specified, the index).

This means that you can use git checkout -p to selectively discard
edits from your current working tree. See the “Interactive Mode”
section of git-add[1] to learn how to operate the --patch mode.

Note that this option uses the no overlay mode by default (see also
--overlay), and currently doesn’t support overlay mode.

—ignore-other-worktrees

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.

—overwrite-ignore

—no-overwrite-ignore

Silently overwrite ignored files when switching branches. This
is the default behavior. Use --no-overwrite-ignore to abort
the operation when the new branch contains ignored files.

—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
local modifications in a submodule would be overwritten the checkout
will fail unless -f is used. If nothing (or --no-recurse-submodules)
is used, submodules working trees will not be updated.
Just like git-submodule[1], this will detach HEAD of the
submodule.

—overlay

—no-overlay

In the default overlay mode, git checkout never
removes files from the index or the working tree. When
specifying --no-overlay, files that appear in the index and
working tree, but not in <tree-ish> are removed, to make them
match <tree-ish> exactly.

—pathspec-from-file=<file>

Pathspec is passed in <file> instead of commandline args. If
<file> is exactly - then standard input is used. Pathspec
elements are separated by LF or CR/LF. Pathspec elements can be
quoted as explained for the configuration variable core.quotePath
(see git-config[1]). See also --pathspec-file-nul and
global --literal-pathspecs.

—pathspec-file-nul

Only meaningful with --pathspec-from-file. Pathspec elements are
separated with NUL character and all other characters are taken
literally (including newlines and quotes).

<branch>

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).

You can use the @{-N} syntax to refer to the N-th last
branch/commit checked out using «git checkout» operation. You may
also specify - which is synonymous to @{-1}.

As a special case, you may use A...B as a shortcut for the
merge base of A and B if there is exactly one merge base. You can
leave out at most one of A and B, in which case it defaults to HEAD.

<new-branch>

Name for the new branch.

<start-point>

The name of a commit at which to start the new branch; see
git-branch[1] for details. Defaults to HEAD.

As a special case, you may use "A...B" as a shortcut for the
merge base of A and B if there is exactly one merge base. You can
leave out at most one of A and B, in which case it defaults to HEAD.

<tree-ish>

Tree to checkout from (when paths are given). If not specified,
the index will be used.

As a special case, you may use "A...B" as a shortcut for the
merge base of A and B if there is exactly one merge base. You can
leave out at most one of A and B, in which case it defaults to HEAD.

—

Do not interpret any more arguments as options.

<pathspec>…​

Limits the paths affected by the operation.

For more details, see the pathspec entry in gitglossary[7].

Merge conflicts occur when competing changes are made to the same line of a file, or when one person edits a file and another person deletes the same file. For more information, see «About merge conflicts.»

Tip: You can use the conflict editor on GitHub to resolve competing line change merge conflicts between branches that are part of a pull request. For more information, see «Resolving a merge conflict on GitHub.»

Competing line change merge conflicts

To resolve a merge conflict caused by competing line changes, you must choose which changes to incorporate from the different branches in a new commit.

For example, if you and another person both edited the file styleguide.md on the same lines in different branches of the same Git repository, you’ll get a merge conflict error when you try to merge these branches. You must resolve this merge conflict with a new commit before you can merge these branches.

1. Open TerminalTerminalGit Bash.

2. Navigate into the local Git repository that has the merge conflict.

   cd REPOSITORY-NAME

3. Generate a list of the files affected by the merge conflict. In this example, the file styleguide.md has a merge conflict.

   $ git status
   > # On branch branch-b
   > # You have unmerged paths.
   > #   (fix conflicts and run "git commit")
   > #
   > # Unmerged paths:
   > #   (use "git add ..." to mark resolution)
   > #
   > # both modified:      styleguide.md
   > #
   > no changes added to commit (use "git add" and/or "git commit -a")

4. Open your favorite text editor, such as Visual Studio Code, and navigate to the file that has merge conflicts.

5. To see the beginning of the merge conflict in your file, search the file for the conflict marker <<<<<<<. When you open the file in your text editor, you’ll see the changes from the HEAD or base branch after the line <<<<<<< HEAD. Next, you’ll see =======, which divides your changes from the changes in the other branch, followed by >>>>>>> BRANCH-NAME. In this example, one person wrote «open an issue» in the base or HEAD branch and another person wrote «ask your question in IRC» in the compare branch or branch-a.

   If you have questions, please
   <<<<<<< HEAD
   open an issue
   =======
   ask your question in IRC.
   >>>>>>> branch-a
   

6. Decide if you want to keep only your branch’s changes, keep only the other branch’s changes, or make a brand new change, which may incorporate changes from both branches. Delete the conflict markers <<<<<<<, =======, >>>>>>> and make the changes you want in the final merge. In this example, both changes are incorporated into the final merge:

   If you have questions, please open an issue or ask in our IRC channel if it's more urgent.

7. Add or stage your changes.

   $ git add .

8. Commit your changes with a comment.

   $ git commit -m "Resolved merge conflict by incorporating both suggestions."

You can now merge the branches on the command line or push your changes to your remote repository on GitHub and merge your changes in a pull request.

Removed file merge conflicts

To resolve a merge conflict caused by competing changes to a file, where a person deletes a file in one branch and another person edits the same file, you must choose whether to delete or keep the removed file in a new commit.

For example, if you edited a file, such as README.md, and another person removed the same file in another branch in the same Git repository, you’ll get a merge conflict error when you try to merge these branches. You must resolve this merge conflict with a new commit before you can merge these branches.

1. Open TerminalTerminalGit Bash.

2. Navigate into the local Git repository that has the merge conflict.

   cd REPOSITORY-NAME

3. Generate a list of the files affected by the merge conflict. In this example, the file README.md has a merge conflict.

   $ git status
   > # On branch main
   > # Your branch and 'origin/main' have diverged,
   > # and have 1 and 2 different commits each, respectively.
   > #  (use "git pull" to merge the remote branch into yours)
   > # You have unmerged paths.
   > #  (fix conflicts and run "git commit")
   > #
   > # Unmerged paths:
   > #  (use "git add/rm ..." as appropriate to mark resolution)
   > #
   > #	deleted by us:   README.md
   > #
   > # no changes added to commit (use "git add" and/or "git commit -a")

4. Open your favorite text editor, such as Visual Studio Code, and navigate to the file that has merge conflicts.

5. Decide if you want keep the removed file. You may want to view the latest changes made to the removed file in your text editor.

   To add the removed file back to your repository:

   $ git add README.md

   To remove this file from your repository:

   $ git rm README.md
    > README.md: needs merge
    > rm 'README.md'

6. Commit your changes with a comment.

   $ git commit -m "Resolved merge conflict by keeping README.md file."
   > [branch-d 6f89e49] Merge branch 'branch-c' into branch-d

You can now merge the branches on the command line or push your changes to your remote repository on GitHub and merge your changes in a pull request.

Further reading

• «About merge conflicts»
• «Checking out pull requests locally»

Системы контроля версий предназначены для управления дополнениями, вносимыми в проект множеством распределенных авторов (обычно разработчиков). Иногда один и тот же контент могут редактировать сразу несколько разработчиков. Если разработчик A попытается изменить код, который редактирует разработчик B, может произойти конфликт. Для предотвращения конфликтов разработчики работают в отдельных изолированных ветках. Основная задача команды git merge заключается в слиянии отдельных веток и разрешении любых конфликтующих правок.

Общие сведения о конфликтах слияния

Слияние и конфликты являются неотъемлемой частью работы с Git. В других инструментах управления версиями, например SVN, работа с конфликтами может быть дорогой и времязатратной. Git позволяет выполнять слияния очень просто. В большинстве случаев Git самостоятельно решает, как автоматически интегрировать новые изменения.

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

Типы конфликтов слияния

Конфликт во время слияния может произойти в двух отдельных точках — при запуске и во время процесса слияния. Далее рассмотрим, как разрешать каждый из этих конфликтных сценариев.

Git прерывает работу в самом начале слияния

Выполнение команды слияния прерывается в самом начале, если Git обнаруживает изменения в рабочем каталоге или разделе проиндексированных файлов текущего проекта. Git не может выполнить слияние, поскольку иначе эти ожидающие изменения будут перезаписаны новыми коммитами. Такое случается из-за конфликтов не с другими разработчиками, а с ожидающими локальными изменениями. Локальное состояние необходимо стабилизировать с помощью команд git stash, git checkout, git commit или git reset. Если команда слияния прерывается в самом начале, выдается следующее сообщение об ошибке:

error: Entry '<fileName>' not uptodate. Cannot merge. (Changes in working directory)

Git прерывает работу во время слияния

Сбой В ПРОЦЕССЕ слияния говорит о наличии конфликта между текущей локальной веткой и веткой, с которой выполняется слияние. Это свидетельствует о конфликте с кодом другого разработчика. Git сделает все возможное, чтобы объединить файлы, но оставит конфликтующие участки, чтобы вы разрешили их вручную. При сбое во время выполнения слияния выдается следующее сообщение об ошибке:

error: Entry '<fileName>' would be overwritten by merge. Cannot merge. (Changes in staging area)

Создание конфликта слияния

Чтобы лучше разобраться в конфликтах слияния, в следующем разделе мы смоделируем конфликт для дальнейшего изучения и разрешения. Для запуска моделируемого примера будет использоваться интерфейс Git c Unix-подобной командной строкой.

$ mkdir git-merge-test
$ cd git-merge-test
$ git init .
$ echo "this is some content to mess with" > merge.txt
$ git add merge.txt
$ git commit -am"we are commiting the inital content"
[main (root-commit) d48e74c] we are commiting the inital content
1 file changed, 1 insertion(+)
create mode 100644 merge.txt

С помощью приведенной в этом примере последовательности команд выполняются следующие действия.

• Создается новый каталог с именем git-merge-test, выполняется переход в этот каталог и инициализация его как нового репозитория Git.
• Создается новый текстовый файл merge.txt с некоторым содержимым.
• В репозиторий добавляется файл merge.txt и выполняется коммит.

Теперь у нас есть новый репозиторий с одной веткой main и непустым файлом merge.txt. Далее создадим новую ветку, которая будет использоваться как конфликтующая при слиянии.

$ git checkout -b new_branch_to_merge_later
$ echo "totally different content to merge later" > merge.txt
$ git commit -am"edited the content of merge.txt to cause a conflict"
[new_branch_to_merge_later 6282319] edited the content of merge.txt to cause a conflict
1 file changed, 1 insertion(+), 1 deletion(-)

Представленная выше последовательность команд выполняет следующие действия.

• Создает новую ветку с именем new_branch_to_merge_later и выполняет переход в нее.
• Перезаписывает содержимое файла merge.txt.
• Выполняет коммит нового содержимого.

В этой новой ветке new_branch_to_merge_later мы создали коммит, который переопределил содержимое файла merge.txt.

git checkout main
Switched to branch 'main'
echo "content to append" >> merge.txt
git commit -am"appended content to merge.txt"
[main 24fbe3c] appended content to merge.tx
1 file changed, 1 insertion(+)

Эта последовательность команд выполняет переключение на ветку main, добавляет содержимое в файл merge.txt и делает коммит. После этого в нашем экспериментальном репозитории находятся два новых коммита, первый — в ветке main, а второй — в ветке new_branch_to_merge_later. Теперь запустим команду git merge new_branch_to_merge_later и посмотрим, что из этого выйдет!

$ git merge new_branch_to_merge_later
Auto-merging merge.txt
CONFLICT (content): Merge conflict in merge.txt
Automatic merge failed; fix conflicts and then commit the result.

БАХ! 💥 Возник конфликт. Хорошо, что система Git сообщила нам об этом.

Выявление конфликтов слияния

Как мы убедились на выполняемом примере, Git выводит небольшое описательное сообщение о возникновении КОНФЛИКТА. Чтобы получить более глубокое понимание проблемы, можно запустить команду git status.

$ git status
On branch main
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:   merge.txt

Вывод команды git status говорит о том, что из-за конфликта не удалось слить пути. Теперь файл merge.text отображается как измененный. Давайте изучим этот файл и посмотрим, что изменилось.

$ cat merge.txt
<<<<<<< HEAD
this is some content to mess with
content to append
=======
totally different content to merge later
>>>>>>> new_branch_to_merge_later

Для просмотра содержимого файла merge.txt воспользуемся командой cat. Видно, что в файле появились новые странные дополнения:

• <<<<<<< HEAD
• =======
• >>>>>>> new_branch_to_merge_later

Эти новые строки можно рассматривать как «разделители конфликта». Строка ======= является «центром» конфликта. Все содержимое между этим центром и строкой <<<<<<< HEAD находится в текущей ветке main, на которую ссылается указатель HEAD. А все содержимое между центром и строкой >>>>>>> new_branch_to_merge_later является содержимым ветки для слияния.

Разрешение конфликтов слияния с помощью командной строки

Самый простой способ разрешить конфликт — отредактировать конфликтующий файл. Откройте файл merge.txt в привычном редакторе. В нашем примере просто удалим все разделители конфликта. Измененное содержимое файла merge.txt будет выглядеть следующим образом:

this is some content to mess with
content to append
totally different content to merge later

После редактирования файла выполните команду git add merge.txt, чтобы добавить новое объединенное содержимое в раздел проиндексированных файлов. Для завершения слияния создайте новый коммит, выполнив следующую команду:

git commit -m "merged and resolved the conflict in merge.txt"

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

Команды Git, с помощью которых можно разрешить конфликты слияния

Общие инструменты

Команда status часто используется во время работы с Git и помогает идентифицировать конфликтующие во время слияния файлы.

При передаче аргумента --merge для команды git log будет создан журнал со списком конфликтов коммитов между ветками, для которых выполняется слияние.

Команда diff помогает найти различия между состояниями репозитория/файлов. Она полезна для выявления и предупреждения конфликтов слияния.

Инструменты для случаев, когда Git прерывает работу в самом начале слияния

Команда checkout может использоваться для отмены изменений в файлах или для изменения веток.

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

Инструменты для случаев, когда конфликты Git возникают во время слияния

При выполнении команды git merge с опцией --abort процесс слияния будет прерван, а ветка вернется к состоянию, в котором она находилась до начала слияния.

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

Резюме

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

Существует множество способов разрешения конфликтов слияния. В этой статье мы рассмотрели немалое количество инструментов командной строки, которые предоставляет Git. Более подробную информацию об этих инструментах см. на отдельных страницах для команд git log, git reset, git status, git checkout и git reset. Помимо этого многие сторонние инструменты также предлагают оптимизированные функции, поддерживающие работу с конфликтами слияния.

Do you get the error message, «Pulling is not possible because you have unmerged files,» when you try to git pull changes? Worry no more.

This tutorial explains the origin of the error message and how to solve it.

Let’s do this!

Understand the basics

Git pull

Let’s start by understanding what git pull entails.

Think of the code tracking environment as a two-part architecture: local and remote environment. In a local environment, we create the project files in a working directory. Next, we stage the changes. We can fall back to untracked files or safely store the files in a repository.

In simple terms, a repository is the version control system’s database. Here, Git refers to the new changes as commits and assigns them unique numbers called commit hashes.

Although the changes are safely stored and can be retrieved, they are local. That means a loss of the computer results in a loss of our files. So, we send the changes to a remote repository through git push.

ALSO READ: git show explained in-depth [Practical Examples]

We can then collaborate with more remote developers, working on the same or separate git branches.  A developer does their part and pushes the changes to the specified branch. To get the other developer’s changes, you do the opposite of git push: git pull.

git pull is the process of updating a local repository with its updated remote version.

Some articles related to this topic:
git pull force Explained
git pull command examples
git pull vs git pull —rebase explained with examples

Git merge

A typical repository has multiple branches: the main branch and its subbranches.

After creating commits in the subbranch, we unite them with the main branch. This process is called git merge. Git merge enables collaboration in a project. Git is intelligent enough to notice the merge timestamps per branch.

Some articles related to this topic:
git merge explained
Git merge vs rebase and the problems they solve

However, here is a catch.

Merge Conflicts

Sometimes Git gets confused when it cannot determine the logical hierarchy of code portions resulting from commits of separate branches. Such a scenario is called a merge conflict.

A merge conflict needs to be resolved. Otherwise, your subsequent pull requests will fail. You can correct the pull error by resolving the merge conflict through a hard reset or manually accepting the new commit’s changes in the script file.

Now that you know the origin and the solution to the typical error, «Pulling is not possible because you have unmerged files,» let’s set up a lab environment and do it practically.

ALSO READ: Git create repository

Lab environment setup

Log into your GitHub account and create a new repo with a README.md file. I am creating one called lab.

Copy the repo URL.

Return to your local machine’s terminal, clone the repo, and cd into it.

Now let’s generate the error: Pulling is not possible because you have unmerged files.

Generate the error: Pulling is not possible because you have unmerged files

Make a commit in the main branch

Let’s create index.html with a title and a description paragraph.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Pulling is not possible because you have unmerged files</title>
</head>
<body>
    <h2>Let's create the error</h2>
    <p>You are about encounter the error: pulling is not possible because you have unmerged files</p>
</body>
</html>

Stage and commit the changes.

git add index.html
git commit -m "Add index.html"

Now we have two commits in the main branch.

git log --oneline

Make a commit in the feature branch

Create a feature branch.

git switch -c feature_branch

And modify the index.html file by adding a paragraph: First, create the feature branch. We use Visual Studio Code to ease the development and manual error correction. Stage the changes and make a commit.

Now the feature branch is ahead of the main branch with a commit.

ALSO READ: git detached HEAD Explained [Easy Examples]

Switch to the main branch, and modify the index.html with a paragraph: Generating the error.

Next, stage the changes and create a commit.

What happens when we attempt to merge the feature branch?

Let’s find out.

Create a merge conflict

Now let’s attempt merging the feature branch’s changes.

Input

git merge feature_branch

Output

user@hostname:~/lab$ git merge feature_branch 
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Git tells us it found a conflict in the index.html file and recommends that we correct the error before proceeding.

Okay, let’s inspect the file.

Input

cat index.html

Output

user@hostname:~/lab$ cat index.html 
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Pulling is not possible because you have unmerged files</title>
</head>
<body>
    <h2>Let's create the error</h2>
    <p>You are about encounter the error: pulling is not possible because you have unmerged files</p>
<<<<<<< HEAD
    <p>Generating the error</p>
=======
    <p>First, create the feature branch</p>
>>>>>>> feature_branch
</body>

Git is stranded on whether the paragraph from the latest commit (HEAD) from the main branch should come first or the feature branch’s paragraph.

<<<<<<< HEAD
    <p>Generating the error</p>
=======
    <p>First, create the feature branch</p>
>>>>>>> feature_branch

We could edit the file to capture our intention before merging the feature branch. However, let’s ignore the call to resolve the conflict. Nor merge the feature branch.

ALSO READ: First Time Git Setup | Git Config Global

Instead, let’s return to the GitHub repository and update the README.md file

Getting error

Now attempt to pull the remote changes.

Input

git pull

Output

user@hostname:~/lab$ git pull
error: Pulling is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.

Git says we have an error: Pulling is not possible because you have unmerged files.

Resolving the error: Pulling is not possible because you have unmerged files

Although we could reset one of the commits, we will retain the changes by accepting both paragraphs in the index.html.

from

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Pulling is not possible because you have unmerged files</title>
</head>
<body>
    <h2>Let's create the error</h2>
    <p>You are about encounter the error: pulling is not possible because you have unmerged files</p>
<<<<<<< HEAD
    <p>Generating the error</p>
=======
    <p>First, create the feature branch</p>
>>>>>>> feature_branch
</body>
</html>

to

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Pulling is not possible because you have unmerged files</title>
</head>
<body>
    <h2>Let's create the error</h2>
    <p>You are about encounter the error: pulling is not possible because you have unmerged files</p>
    <p>Generating the error</p>
    <p>First, create the feature branch</p>
</body>
</html>

Then, stage and commit the changes.

ALSO READ: Git merge vs rebase and the problems they solve

Input

git add .
git commit -m "Accept both paragraphs"

Output

user@hostname:~/lab$ git add .
user@hostname:~/lab$ git commit -m "Accept both paragraphs"
[main 308f222] Accept both paragraphs

Now git pulling does not produce the primary error.

Input

git pull

Output

user@hostname:~/lab$ git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 779 bytes | 194.00 KiB/s, done.
From github.com:Stevealila/lab
   634d087..4685287  main       -> origin/main
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint: 
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint: 
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.

Although the pull process goes through, we get some warnings. The relieving part is that Git gives us some hints on how to get rid of the warnings.

Summary

The error, «Pulling is not possible because you have unmerged files,» often results from attempting to git pull changes without resolving local merge conflicts. As shown in this tutorial, you can correct the conflicts before proceeding with git pull.

ALSO READ: git fetch vs git pull Explained [With Examples]

A merge conflict is not the end of the world. Actually, if you keep a couple of things in mind, solving conflicts is easy as pie:

(1) Keep Calm

Above all, you need to realize that you cannot break anything: Git always allows you to go back to the state before the conflict occurred. With a simple «git merge —abort«, you can always undo the merge and start over again. This makes it almost impossible to severely screw things up.

(2) How do I Know I Have a Conflict?

When calling «git status», you’ll see a special Unmerged paths category. All of the items in this category are in a conflict state and need to be dealt with:

$ git status
# On branch contact-form
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#
# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
#
#       both modified:   contact.html
#
no changes added to commit (use "git add" and/or "git commit -a")

(3) Understand When & Why a Conflict Happens

Conflicts occur when the same file was changed in contradictory ways. Most modifications don’t fall into this category: if two people just work on the same file, Git can most likely figure things out on its own.
The most common situation when it cannot do this is when the exact same lines were edited in that file. In that case, Git has no way of knowing what’s correct — you’ll have to look at the changes and decide how you want the file to finally look.

(4) A Conflict is Just an Annotation

It helps to realize that a conflict is nothing magical. In the concerned file, Git simply marks the areas that were edited in contradictory ways:

This helps you understand which edits were made — and even on which branches.

(5) Solving Means Choosing & Editing

Your job now is to condition the file to its desired state. There are a couple of ways to do this:

(a) You can simply open the file in an editor, search for the conflict markers (see above image) and make any necessary modifications. When you’re done, the file needs to look exactly as you want it to look.
(b) Alternatively, you can tell Git that you’ll simply go with one of the edited versions, called «ours» or «theirs».

git checkout --ours path/to/conflict-file.css

Note that there are lots of dedicated «Merge Tool» applications that help you with this process. Especially in complex situations with multiple conflicts in the same file, a good tool can be of tremendous value. We’ve compiled a list of merge tools in our free ebook.

(6) Wrap Up

When you’ve successfully solved all conflicts, you need to do two more things:

(1) Mark each conflicted file as solved. A simple «git add <filepath>» does this for you.
(2) Commit the resolution just as you would commit any other change with the «git commit» command.

Solving Conflicts in Tower

In case you are using the Tower Git client, its visual Conflict Wizard will help you solve merge conflicts more easily:

Learn More

• Check out the chapter Dealing with Merge Conflicts in our free online book
• More frequently asked questions about Git & version control

Two ways git merge/git pull can fail

There are 2 ways in which git merge (or a git pull, which is a git fetch and then a git merge) can fail:

Git can fail to start the merge

This occurs because git knows there are changes in either your working directory or staging area that could be written over by the files that you are merging in. If this happens, there are no merge conflicts in individual files. You need to modify or stash the files it lists and then try to do a git pull again. The error messages are as follows:

error: Entry '<fileName>' not uptodate. Cannot merge. (Changes in working directory)

or

error: Entry '<fileName>' would be overwritten by merge. Cannot merge. (Changes in staging area)

Git can fail during the merge

This occurs because you have committed changes that are in conflict with someone else’s committed changes. Git will do its best to merge the files and will leave things for you to resolve manually in the files it lists. The error message is as follows:

CONFLICT (content): Merge conflict in <fileName>
Automatic merge failed; fix conflicts and then commit the result.

Common questions for when git fails during the merge

How do I know which files have conflicts in them?

If your merge failed to even start, there will be no conflicts in files. If git finds conflicts during the merge, it will list all files that have conflicts after the error message. You can also check on which files have merge conflicts by doing a ‘git status’.

Example:

  # Changes to be committed:
  #   (use "git reset HEAD <file>..." to unstage)
  #
  #	modified:   <Some file>
  #
  # Changed but not updated:
  #   (use "git add <file>..." to update what will be committed)
  #   (use "git checkout -- <file>..." to discard changes in working directory)
  #
  #	unmerged:   <file>
  #

«Changes to be committed»: All committed changes to files that are not affected by the conflict are staged.

«Changed but not updated … unmerged»: All files that have conflicts that must be resolved before repository will be back to working order.

How do I find conflicts within the file itself?

Conflicts are marked in a file with clear line breaks:

 <<<<<<< HEAD:mergetest
 This is my third line
 =======
 This is a fourth line I am adding
 >>>>>>> 4e2b407f501b68f8588aa645acafffa0224b9b78:mergetest

<<<<<<<: Indicates the start of the lines that had a merge conflict. The first set of lines are the lines from the file that you were trying to merge the changes into.

=======: Indicates the break point used for comparison. Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences.

>>>>>>>: Indicates the end of the lines that had a merge conflict.

How do I resolve a merge conflict in a file?

You resolve a conflict by editing the file to manually merge the parts of the file that git had trouble merging. This may mean discarding either your changes or someone else’s or doing a mix of the two. You will also need to delete the ‘<<<<<<<‘, ‘=======’, and ‘>>>>>>>’ in the file.

What do I do after I’ve resolved conflicts in all affected files?

git add the file(s), git commit and git push (Push only for branches tracked.)

(Note added by Chin — need to commit everything, not just the resolved conflict file.)

Tools to help you resolve both types of merge conflicts

The following git tools below can help you resolve both simple and more complicated git merges.

General tools

git diff

git diff: a command that helps find differences between states of a repository/files. Useful in predicting and preventing merge conflicts.

git diff origin/master <fileName>: Find the differences between the current index (HEAD) of fileName and what is in the central repository (origin/msater)

diff --git a/mergetest b/mergetest
index 9be56b9..0aeffac 100644
--- a/mergetest
+++ b/mergetest
@@ -1,3 +1,4 @@
 hello
+I am also editing this line
 This is a test
-This is my third line
+This is a fourth line I am adding

Changes coming from origin/master are marked with +, while changes that are in your local repository (HEAD) are marked with —. This syntax does not notify which lines are added are deleted but just which lines originate in which state of the file.

git diff FETCH_HEAD <fileName>: Will provide the same output as above except is limited to the index of the last fetch that the user did. This may not be latest revision in the central repository.

git status

git status: a command provides an overview of all files that have been modified and are in conflict at the time of the merge.

Example:

   # Changes to be committed:
   #   (use "git reset HEAD <file>..." to unstage)
   #
   #	modified:   <Some file>
   #
   # Changed but not updated:
   #   (use "git add <file>..." to update what will be committed)
   #   (use "git checkout -- <file>..." to discard changes in working directory)
   #
   #	unmerged:   <file>
   #

• «Changes to be committed»: All changes to files that are not affected by the conflict are staged.

• «Changed but not updated … unmerged»: All files that have conflicts that must be resolved before repository will be back to working order.

Tools specifically for when git refuses to start merge

git stash

IMPORTANT: Do not use git stash if git went through with the merge and there were merge conflicts! Only use git stash if git refused to merge because it foresees there being conflicts.

git stash: stashes away any changes in your staging area and working directory. This command is useful in saving all changes not ready to be committed and the user wants to have an updated repository.

git stash save «<Save Message>»: Save changes to files in working directory and staging area that git is aware of

 git stash save "Saved changes for stash example"
 Saved working directory and index state "On master: Saved changes for stash example"
 HEAD is now at 4e2b407 Added second file for example.

git stash pop: Removes the most recent stash or any stash specified and applies changes as a merge. If merge fails the stash is not removed from the list and must be removed manually.

git checkout

git checkout <fileName>: Can be used to trash changes in the working directory so as to allow a git pull.

git reset —mixed

git reset —mixed: Can be used to unstage files so as to allow a git pull.

Tools specifically for when git conflicts arise during a merge

git reset

git reset —hard: reset repository in order to back out of merge conflict situation. git reset, particularly with the —hard option can be used to back out of merge conflict (click here for more information).

IMPORTANT: Do not use any other options other than —hard for reset when resolving a situation where git failed during the merge, as they will leave conflict line markers in file and you can end up committing files with conflict markers still present.

Scenarios

Git refuses to start a merge/pull

Error Messages:

error: Entry '<fileName>' not uptodate. Cannot merge. (Changes in working directory)

error: Entry '<fileName>' would be overwritten by merge. Cannot merge. (Changes staged, but not commited)

Steps toward Resolution:

1. git stash save «<Message that describes what is being Saved>» (Stashes away any changes in your staging area and working directory in a separate index.) OR git checkout <file> (throws out your changes so that you can do a merge)
2. git status (Verify all changes are staged)
3. git pull or git merge (Bring in changes from central repository or another branch)
4. Only if did a ‘git stash’ in step 1: git stash pop (Will repopulate your changes into your working directory, may have to resolve merge conflicts)

Git is unable to resolve a merge/pull

Error Message:

CONFLICT (content): Merge conflict in <fileName>
Automatic merge failed; fix conflicts and then commit the result.

Steps toward Resolution:

1. git status (Shows all files that are in conflict as unmerged changed in working directory.)
2. Resolve merge conflicts
3. git add <files>
4. git commit -m «<Informative commit message>»

A GitHub test repository to experiment with conflicts

You can experiment with resolving a git conflict with this repository: https://github.com/brianleetest/testGit/blob/master/README.md

1. You will need a GitHub account and be added as a collaborator to push your changes.
2. Create two separate directories, gitClone and gitCloneLeader in two different terminals and locations. The leader can be the first to push changes (requires being a collaborator).
3. Do the first «Group Member» steps up until WAIT in the gitClone directory.
4. Then do all of the «Group Leader» steps in the gitCloneLeader directory (push required to cause conflict).
5. Continue the «Group Member» steps (first git pull since cloning the repository and editing the file).

Git is the standard source code repository manager for open source projects and many closed source projects. This article shows new Git users how to do something slightly advanced but fundamental to its purpose: resolving a git-merge conflict.

What is a git merge?

All modern source-control systems have an essential feature: the ability for multiple developers to work on the same project, at the same time, without interfering with each other. Git implements this feature by allowing multiple developers to work on a branch locally, then push their code to a central place. Then, others can pull the code back to their local copy and continue their own work with their collaborators’ changes in place.

When you want to bring the changes in a branch into your current branch, you use a git merge command. The merge takes all the changes in the other branch and applies them to the current branch.

What is a merge conflict?

In every situation where work can be parallelized, work will eventually overlap. Sometimes two developers will change the same line of code in two different ways; in such a case, Git can’t tell which version is correct—that’s something only a developer can decide.

If this happens, a developer will see the following error during a git merge:

Auto-merging [filename1]
CONFLICT (content): Merge conflict in [filename1]
Automatic merge failed; fix conflicts and then commit the result.

Resolving merge conflicts can take a minute or they can take days (if there are a lot of files that need to be fixed). It’s recommended, and good coding practice, to sync your code multiple times a day by committing, pushing, pulling, and merging often.

How do you resolve a git merge conflict?

Git gives a clue to resolving conflicts in its error message. It says Merge conflict in [filename1], so you know there is a problem with that file. Then it says fix conflicts and then commit the result, so if you follow directions, edit the file, then commit it, everything should work fine. Let’s see this in action.

Create a new Git repo, add a file, make a branch, make some conflicting edits, and see what it looks like.

Start with an empty directory and run git init:

$ ls -l
$ git init
Initialized empty Git repository in /home/bob/example/.git/
$

Now create a README file and commit the changes:

$ echo "This is a new README file" > README.md
$ cat README.md
This is a new README file
$ git add README.md
$ git commit -m "README file added"
1 file changed, 1 insertion(+)
create mode 100644 README.md
$ git status
On branch master
nothing to commit, working tree clean
$

Create a new branch:

$ git checkout -b "branch_to_create_merge_conflict"
Switched to a new branch 'branch_to_create_merge_conflict'

On the new branch:

$ git branch
* branch_to_create_merge_conflict
master

Make an edit:

This is a new README file

This is an edit on the branch

Now commit that edit:

$ vim README.md
$ git add README.md
$ git commit -m "Edits made to README on the branch"
[branch_to_create_merge_conflict 9c5e88a] Edits made to README on the branch
1 file changed, 2 insertions(+)

Return to the master branch, edit the README on line 3 with something different, and commit that.

Change to the master branch:

$ git checkout master
Switched to branch 'master'

Edit the README:

This is a new README file

This is an edit on the master branch

Commit the edit:

$ git add README.md
$ git commit -m "Edits made to README on the master branch"
[master 7ea2985] Edits made to README on the master branch
1 file changed, 2 insertions(+)

Merge the branch into master to see the error:

$ git branch
  branch_to_create_merge_conflict
* master
$ git merge branch_to_create_merge_conflict
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

Now, go into the README file, as Git asks, to see what it looks like:

This is a new README file

<<<<<<< HEAD
This is an edit on the master branch
=======	
This is an edit on the branch
>>>>>>> branch_to_create_merge_conflict

As you can see, Git added some syntax including seven «less than» characters, <<<<<<< and seven «greater than» characters, >>>>>>>, separated by seven equal signs, =======. These can be searched using your editor to quickly find where edits need to be made.

That there are two sections within this block:

• The «less than» characters denote the current branch’s edits (in this case, «HEAD,» which is another word for your current branch), and the equal signs denote the end of the first section.
• The second section is where the edits are from the attempted merge; it starts with the equal signs and ends with the «greater than» signs.

As a developer, you decide what stays and what goes. Make your edits as necessary, then close the file:

This is a new README file

This is an edit on the branch

As you can see, this keeps the branch’s edits. You can run git status to see further instructions:

$ vim README.md
$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add ..." to mark resolution)
  both modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")

Notice that if you run into serious issues, you can abort the merge by running git merge —abort to abort the merge.

Follow the directions to add the file and then commit:

$ git add README.md
$ git status
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)

Changes to be committed:
modified: README.md

$ git commit
[master 9937ca4] Merge branch 'branch_to_create_merge_conflict'

Key takeaways and further reading

Merge conflicts are going to happen on teams of any size, given enough time. It’s important to be able to resolve them with a clear head. As a developer, I’ve been quite overwhelmed staring at a 10+ file merge-conflict problem. Understanding what you are looking at when you get a merge conflict goes a long way.

I didn’t cover merge conflicts in the context of an integrated development environment. Knowing how to use the Git command-line tool, including fixing merge conflicts, is indispensable to understanding Git and being able to work on Git in any environment.

Git’s website and documentation are good resources if you get stuck. You can find advanced information on Git merging, including merge-conflict resolution, in the advanced merging section of the Git Pro book.

This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.