128

I tried to merge a file in the command line using Git, when an error message appeared telling me the merge was aborted.

I thought that was the end of it, but then I realized there are gitmarks in my files. Like so:

start =
    expression

validchar = 
    [0-9a-zA-Z_?!+\-=@#$%^&*/.]

integer = 
<<<<<<< HEAD
    digits:[0-9]+
        { return digits.join(""); }
=======
    sign:"-"* digits:[0-9]+
        { return sign + digits.join(""); }
>>>>>>> gh-pages

The files have been edited not by me and show lines inserted with:

  • HEAD after less than signs (<<<<<<< HEAD)
  • lines of changed code
  • a string of equals signs (=======)
  • the new version of the code
  • another line starting with greater than signs and the name of the branch (>>>>>>> gh-pages)

What's worse is that the file contents are no longer in order. Does anyone know how I get those files back to normal, and the changes I made in the gh-branch merged into the master branch?

lowerkey
  • 8,105
  • 17
  • 68
  • 102
  • If you didn't really want to merge anything (or thought it wouldn't be necessary), landed here, and are freaking out about advice to "hand edit those parts" in dozens of files, `git merge --abort` reverted my local folder to its previous state. `git status` suggested that to me. If you really want to edit them, `git mergetool` (as in the answer further below) is probably good enough. – Fons MA Jan 05 '21 at 00:20

6 Answers6

120

Those are conflict markers. You're still in the process of merging, but there were some parts that Git couldn't merge automatically. You'll need to hand-edit those parts to what you want them to be and then commit the results.


For instance, in your particular case, you'd probably want to resolve it like this (note - the arrows/text on the right are just my notes, not something you'd type into the file):

integer = 
<<<<<<< HEAD                                  <-+ remove the bits here
    digits:[0-9]+                               |
        { return digits.join(""); }             |
=======                                       <-+
    sign:"-"* digits:[0-9]+
        { return sign + digits.join(""); }
>>>>>>> gh-pages                              <-- and this

and thus you'd save the file as...

integer = 
    sign:"-"* digits:[0-9]+
        { return sign + digits.join(""); }
Community
  • 1
  • 1
Amber
  • 507,862
  • 82
  • 626
  • 550
  • 6
    @lowerkey Exactly how you want the end merged result to look. My guess is that you really just want the portion in the `gh-pages` version, so you'd just delete the stuff from `<<<<<<` to `======` and also remove the single `>>>>>>` line, leaving the two lines of actual code between `=======` and `>>>>>>`. – Amber May 18 '12 at 17:51
  • Thanks, I think I'm getting the hang of it. Delete everything from head to ====== and then remove the leftover HEADmarks. – lowerkey May 18 '12 at 17:56
  • I read at http://www.sbf5.com/~cduan/technical/git/git-3.shtml that after I'm done editing the files (although the tutorial didn't tell me the crucial part about removing parts from <<<<< to ===== (because I want everything from gh-pages)) I have to add the edited file and commit, and git will take care of the rest. is that right? – lowerkey May 18 '12 at 17:59
  • 1
    Yep, that's correct. (There's no real "rest" to take care of - you're just committing the results of the merge, which Git would normally do automatically if there weren't conflicts.) – Amber May 18 '12 at 18:09
  • 2
    @lowerkey, please also consider [reading a book](http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging#Basic-Merge-Conflicts) on the topic. I would recommend to read that book in its entirety as you appear to lack certain basic knowledge about how VCSes work and it's better to get yourself prepared for possible problems in the future. – kostix May 19 '12 at 16:51
  • http://matthew-brett.github.io/pydagogue/foundation.html is a good start and a bit more lightweight than a book – niefpaarschoenen Sep 26 '13 at 09:21
  • @lowerkey please please please consider using a merge tool like meld that let's you visually see what is conflicting. I used to do all my merges by hand but when someone showed me that app it was a god send. You can set it up as your merge tool in git and then after a conflict just use the command `git mergetool` – karina May 05 '16 at 11:19
  • Which changes are which? I constantly get confused. Is "HEAD" *my* changes, or the ones from the conflicting commit? – Ben Farmer May 23 '16 at 07:40
  • `HEAD` always refers to the commit you have checked out. – Amber May 25 '16 at 19:46
  • 1
    How funny is that. You point to an answer of the question that is being marked as a duplicate of this one although the answer to this question can be found in the other question. – t3chb0t Dec 23 '17 at 10:53
  • TortoiseHg pops up a merge tool to help you resolve these with built-in merge and visual diff. I merged for years without seeing the actual <<<<< marks. Hand editing is a ridiculous suggestion for a user experience, but Git don't care. – Noumenon Aug 01 '18 at 02:54
26

Absolutely start with 'git status' to see what you've got. If you aborted a merge (or had a merge aborted) and you've got conflicted files in the working directory then something went wrong. The Git status will tell you where you are. After that, you have a number of options. You should resolve the merge commit either by-hand, which can be challenging, or using a tool as:

git mergetool

The merge tool will work if your files are listed as needing a merge.

You can also perform one of:

git checkout --ours -- /path/to/conflicted-file       # this is probably the one you want
git checkout --theirs -- /path/to/conflicted-file

You can see the different versions using the :1:filename syntax. See here for an explanation. But all of the above assumes that 'git status' shows the files as needing a merge.

Finally, you always have the option of:

git reset --hard   # sounds like --hard is what you need but check other options
Community
  • 1
  • 1
GoZoner
  • 67,920
  • 20
  • 95
  • 145
  • 9
    I'd absolute like to second the "start with `git status` to see what you've got" advice: it's fasionable in some circles to blame Git for its imaginary complexity, but in fact careful reading the output of `git status` is enough to understand what to do next in most common situations. Hence, really: if something goes wrong, stop, read `git status`, think. – kostix May 19 '12 at 16:54
6

All of the answers are right but if you want to Autoremove all conflict marks & want to autochange the files to keep HEAD , then You can create your own bash script like :-

Example Script:

# vim /usr/sbin/solve.git

(Append Following)

#!/bin/bash
for f in $(grep -Rl '^>>>>>>> ' --include="*.php" --include="*.css" --include="*.js" --include="*.html" --include="*.svg" --include="*.txt" .)
do
sed -i -e '/^=======/,/^>>>>>>> /d' -e '/^<<<<<<< /d' $f
sed -i -e '/^>>>>>>> /d' $f
echo "$f Fixed"
done
git add . ; git commit -am "[+] Resolved on `date` from `hostname` by `whoami`" --no-verify

# chmod 755 /usr/sbin/solve.git

& just run it in your GIT repo/path to resolve:

$ cd <path_to_repo>
$ solve.git

Notice:- Above mentioned file extensions are php,css,js,html,svg & txt.

Mr. Pundir
  • 549
  • 6
  • 10
0

In Atom i had the issue that some files did not save the resolved merge conflicts to the drive, so i had to manually click "save". Took me quite some time to figure out.

Timar Ivo Batis
  • 1,861
  • 17
  • 21
0

I'm coming from this question. And I wanted some automated method of merging the half merged files, instead of manually editing the files (as suggested in other answers, which I am not really comfortable doing). So here's what I ended up doing via netbeans, but can be done via command line too.

Now, bear in mind, this only works if immediately after the merge->add->commit, you realised that you messed up, and want to re-go through the process.

STEP 1: Reset to a previous commit.

git reset --hard a992a93f9312c6fa07c3a1b471c85e9fbf767d0e

STEP 2: Re-Try Merging the branch

git merge --ff origin/feature/YOUR-Branch_here

At this point you shall be prompted with the merging window if you are using a GUI. and you can then proceed as normal.

Mohd Abdul Mujib
  • 13,071
  • 8
  • 64
  • 88
0

If you want to consider the new changes (coming from the branch to be merged), then remove all the code belonging to the HEAD. And if you want to keep your own code and not the code of the new branch, then remove the other and keep the HEAD's code