Merging multiple conflicts | PracticalSeries: Brackets-Git and GitHub

F.1 Multiple conflicts in multiple files with Brackets

In section 6.7 I looked at merging files together and resolving conflicts; however, I only did this with a single conflict. Life, on the other hand, is usually more complicated than this and it’s fairly common to have more than one conflict and these can be in multiple files all at the same time.

Brackets handles all this and it will present each change with the usual mechanism discussed in § 6.7.3. It looked like this if you remember:

<<<<<<< HEAD
CHANGE A
=======
CHANGE B
>>>>>>> BranchName

In that section it was easy, there was only one conflict and Brackets helpfully opened and displayed it in its main window with the cursor positioned at the start of the <<<<<<< line.

Things get a bit more complicated with multiple conflicts and it can be a bit difficult keeping track if you have a large number of them; but Brackets will tell you where they all are, it just needs a bit of discipline (I don’t mean that in an oo’er missus, Carry On-esk sort of way).

So it’s back to the London Underground. I’m going to start this example with the last entry in the lab-01-website repository. This was [780b895]; we did this in section 10.2.5 where we looked at issues. If you are coming to this from section 6.7.4. don’t worry, the files are pretty much the same. It all looks like this (I’ve given it a final P08 tag for completeness):

Figure F.1 - The lab-01-website final workflow position

index.html

<html lang="en">                          <!-- Declare language -->
    <head>                                <!-- Start of head section -->
        <meta charset="utf-8">            <!-- Use Unicode char set  -->

<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

        <title>PracticalSeries: Git Lab</title>
    </head>

    <body>
        <h1>A Practical Series Website</h1>

        <figure class="cover-fig">
            <img src="11-resources/02-images/logo.png" alt="cover logo">
        </figure>

        <h3>A note by the author</h3>

<p>This is my second Practical Series publication—this one happened by accident too. The first publication is all about building a website, you can see it here. This publication came about because I wanted some sort of version control mechanism for the first publication.</p>

    </body>
</html>

Code F.1 index.html

01-intro.html

<html lang="en">                          <!-- Declare language -->
    <head>                                <!-- Start of head section -->
        <meta charset="utf-8">            <!-- Use unicode char set  -->

<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

        <title>PracticalSeries: Git Lab - Introduction</title>
    </head>

    <body>
        <h1>A Practical Series Website</h1>

        <h3>Introduction</h3>

<p>This page is an introduction to the website and how to use it.</p>

    </body>
</html>

Code F.2 01-intro.html

02-about.html

<html lang="en">                            <!-- Declare language -->
    <head>                                  <!-- Start of head section -->
        <meta charset="utf-8">              <!-- Use unicode char set  -->

<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

        <title>PracticalSeries: Git Lab — About us</title>
    </head>

    <body>
        <h1>A Practical Series Website</h1>

        <h3>About Us</h3>

<p>This page explains who we are and how we came to be doing this.</p>

    </body>
</html>

Code F.3 02-about.html

03-contact.html

<html lang="en">                            <!-- Declare language -->
    <head>                                  <!-- Start of head section -->
        <meta charset="utf-8">              <!-- Use unicode char set  -->

<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

        <title>PracticalSeries: Git Lab — Contact us</title>
    </head>

    <body>
        <h1>A Practical Series Website</h1>

        <h3>Contact Us</h3>

<p>This page explains how to email Practical Series.</p>

    </body>
</html>

Code F.4 03-contact.html

04-legal.html

<html lang="en">                            <!-- Declare language -->
    <head>                                  <!-- Start of head section -->
        <meta charset="utf-8">              <!-- Use unicode char set  -->

<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

        <title>PracticalSeries: Git Lab — legal</title>
    </head>

    <body>
        <h1>A Practical Series Website</h1>

        <h3>Legal Declaration</h3>

<p>This page contains the legal information for the website.</p>

    </body>
</html>

Code F.5 04-legal.html

style.css

* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
    position: relative;
}

html {
    background-color: #fbfaf6;      /* Set cream coloured page backgrnd */
    color: #404030;
    font-family: serif;
    font-size: 26px;
    text-rendering: optimizeLegibility;
}

body {
    max-width: 1276px;
    margin: 0 auto;
    background-color: #fff;         /* make content area backgrnd white */
    border-left: 1px solid #ededed;
    border-right: 1px solid #ededed;
}

h1, h2, h3, h4, h5, h6 {            /* set standard headings */
    font-family: sans-serif;
    font-weight:normal;
    font-size: 3rem;
    padding: 2rem 5rem 2rem 5rem;
}
h3 { font-size: 2.5rem; color: #404030; }

.cover-fig {                        /* holder for cover image */
    width: 50%;
    margin: 2rem auto;
    padding: 0;
}
.cover-fig img {width: 100%;}       /* format cover image */

p {                                 /* TEXT STYLE - paragraph */
    margin-bottom: 1.2rem;          /* THIS SETS PARAGRAPH SPACING */
    padding: 0 5rem;
    line-height: 135%;
}

Code F.6 style.css

I’ve zipped the whole thing up and you can get it here: _a

It all looks like this:

That’s one dull website.

These files are all stored on the master branch and no other branch exists.

F.1.1 Creating multiple conflicts with Brackets

Ok, here’s what I’m going to do, I’m going to create a new branch (d09-modifications) and then modify the files on both the new branch and the master branch in such a way that the modifications conflict with each other. I’m going to make the following changes:

Two conflicting changes to style.css giving multiple conflicts in the same file
A single conflicting change to 01-intro.html giving an additional conflict in another file
A non-conflicting change in 03-contact.html to demonstrate how this is handled at the same time

Let’s start then. Create a new branch d09-modifications and change to it:

Figure F.7 - The lab-01-website new d09-modifications branch

Now let’s modify style.css. Make the following two changes — these are just to the colour of the heading and body text:

style.css

html {
    background-color: #fbfaf6;      /* Set cream coloured page backgrnd */
    color: #000;
    font-family: serif;
    font-size: 26px;
    text-rendering: optimizeLegibility;
}


  . . .

h3 { font-size: 2.5rem; color: #ff0000; }

Code F.7 style.css modified on d09-modifications branch

I’ve changed the body text to black, #000 (it was grey #404030) in line 10 and I’ve changed the <h3> heading colour to bright red (line 30).

Next make a change to the 01-intro.html file:

01-intro.html

<html lang="en">                          <!-- Declare language -->
    <head>                                <!-- Start of head section -->
        <meta charset="utf-8">            <!-- Use unicode char set  -->

<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

        <title>PracticalSeries: Git Lab - Introduction</title>
    </head>

    <body>
        <h1>A Practical Series Website</h1>

        <h3>Foreword</h3>

<p>This page is an introduction to the website and how to use it.</p>

    </body>
</html>

Code F.8 01-intro.html modified on d09-modifications branch

I’ve changed its heading from Introduction to Foreword (line 13).

Finally for this branch, change the 03-contact.html file to:

03-contact.html

<html lang="en">                            <!-- Declare language -->
    <head>                                  <!-- Start of head section -->
        <meta charset="utf-8">              <!-- Use unicode char set  -->

<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

        <title>PracticalSeries: Git Lab — Contact us</title>
    </head>

    <body>
        <h1>A Practical Series Website</h1>

        <h3>Contact</h3>

<p>This page explains how to email Practical Series.</p>

    </body>
</html>

Code F.9 03-contact.html modified on d09-modifications branch

I’ve just taken the Us from the end of Contact Us (this will be the non-conflicting modification).

Commit these changes with the commit message:

d-P08.09.01: Multiple Conflict Demonstration
style.css modified(body text colour and h3 colour) 01-intro.html modified 03-contact.html modified

I get commit point [ae52fa1] and the workflow looks like this:

Figure F.8 - The lab-01-website first set of changes

Ok, back to the master branch and make the following changes (I know I said don’t make changes on the master branch, but it’s just an example, let’s not make it overly complicated).

Here we go, make sure you are on the master branch.

First make the following conflicting changes to style.css. These are identical to those of Code F.6 but with different colours:

style.css

html {
    background-color: #fbfaf6;      /* Set cream coloured page backgrnd */
    color: #d6d6d6;
    font-family: serif;
    font-size: 26px;
    text-rendering: optimizeLegibility;
}


  . . .

h3 { font-size: 2.5rem; color: #0000ff; }

Code F.10 style.css modified on master branch

This time (in line 10), I’ve change the body text to a lighter grey, #d6d6d6, (this will conflict with the black on d09-modifications) and I’ve changed the <h3> heading colour to bright blue (line 30), again this will conflict with the red in d09-modifications.

Now make a change to the 01-intro.html file:

01-intro.html

<html lang="en">                          <!-- Declare language -->
    <head>                                <!-- Start of head section -->
        <meta charset="utf-8">            <!-- Use unicode char set  -->

<link rel="stylesheet" type="text/css" href="11-resources/01-css/style.css">

        <title>PracticalSeries: Git Lab - Introduction</title>
    </head>

    <body>
        <h1>A Practical Series Website</h1>

        <h3>Preface</h3>

<p>This page is an introduction to the website and how to use it.</p>

    </body>
</html>

Code F.11 01-intro.html modified on master branch

I’ve changed its heading from Introduction to Preface (line 13); this will conflict with Foreword in the d09-modifications branch.

I’m not going to make any changes to 03-contact.html, the change on d09-modifications will go through without conflict.

Commit these changes with the commit message:

MASTER: Multiple Conflict Demonstration
style.css modified (body text colour and h3 colour) 01-intro.html modified

I get commit point [966e3a2] and the workflow looks like this:

Figure F.9 - The lab-01-website conflicting set of changes

F.1.2 Merging multiple conflicts with Brackets

At this point if we try to merge d09-modifications back into the master branch we will have the following situation:

Two conflicting changes to style.css giving multiple conflicts in the same file
A single conflicting change to 01-intro.html giving an additional conflict in another file
A non-conflicting change in 03-contact.html to demonstrate how this is handled at the same time

Let’s do it and see what we get. Make sure you are on the master branch and try to merge the d09-modification branch into it (from the branch drop down select the merge icon):

First we get the merge pop-up

Leave everything as it is and click ok.

Next we get the usual (and unhelpful) merge result message:

Click close and let’s see what we’ve got.

Figure F.13 - Merge with a conflict result in Brackets

The important stuff is at the bottom, I’ll make it a bit bigger:

It sort of makes sense, it knows that three files have been modified (style.css, 01-intro.html and 03-contact.html); the difference is that 03-contact.html has already got a tick next to it and it says “staged, modified”.

What this means is that Brackets knows 03-contact.html has been modified, but it has staged it because there is no conflict — and that is right, if you remember we modified 03-contact.html on the d09-modification branch, but this was the modification without conflict (no counterpart modification on the master branch).

So when there is a conflict, Brackets will list all the modified files, but the ones with a tick next to them have no conflict and we don’t need to do anything with them — easy, ignore the ticked files.

Now let’s have a look at the other files, style.css first. Click it in the Git pane at the bottom (or in the file tree on the left, they both do the same) to open it. It opens in the main window and mine looks like this (this is exactly as it was when it opened):

Figure F.15 - style.css with first conflict

It’s opened style.css and we can see the first conflict (this is just a coincidence; it is just showing the file from line 1).

Now this is the difficult bit, Brackets isn’t telling us how many conflicts exist in this file. If we scroll down the file the next conflict can be seen:

Figure F.16 - style.css with second conflict

These conflicts are fairly easy to see, they’ve got big red dots next to them: , but this is just the linter extension flagging up that the <<<<<<, ======= and >>>>>>> lines don’t conform to CSS (or HTML for that matter). If the conflict were in a comment area, there would be no red dot (CSS and HTML don’t care what is in a comments field) and the linter won’t notice it.

The best way to make sure you’ve identified all the conflicting modification is to search for the <<<<<<< string (you could also search for the >>>>>>> string, I can’t search for the ======= string because I use it everywhere as a divider in my comments).

To find all the <<<<<<< hit ctrl+f and enter it (alternatively, file → find).

They show up like this:

The number next to the search box (highlighted in blue) shows how many occurrences (or conflicts exist), two in this case indicated by the 1 of 2 (the current selection is shown in darker yellow).

Let’s fix the conflicts; I’m going to change the body text (first conflict) back to the original #404030 colour. With the second conflict, I’m going to pick the blue (HEAD) option. The corrected file looks like this:

The changes are in line 10 and line 30 (highlighted). I’ve also ticked the box next to the style.css file in the Git pane to show I’ve completed the changes to the file.

Finally, click the 01-intro.html file to open it.

There is only one conflict, I went for Preface, made the change and ticked the box:

Figure F.20 - 01-intro.html corrected file

That gives all three files ready for the commit (all files are “staged, modified”). Click the commit button to do it.

Figure F.21 - Commit resolved conflict, default message

I kept the default message — click ok to commit the changes. The work flow is now:

It is now possible to delete the d09-modifications branch (see § 6.7.2).

F.1.3 Summary of multiple conflicts

What to do in the event of multiple conflicts:

After the merge, the abort merge button () will be visible in the Git pane (indicating that a conflict exists), the branch will also be showing |MERGING after the branch name.
The ticked files in the Git pane do not have any conflicts, these will be listed as staged, modified.
Open each of the remaining (unticked) files in turn and search (ctrl+f) for <<<<<<< (seven less-than signs)
The last number (Y) of the X of Y in the search box shows how many conflicts exist in the file (these will be highlighted in yellow)
Correct each conflict in the file (re-hit ctrl+f. if the search box closes)
When all conflicts in the file are resolved, tick the commit box for the file in the Git pane, this will now show the file as staged, modified.
When all conflicts in all files have been resolved (all files are ticked and show staged, modified), press the commit button to commit the changes.

F.2 Multiple conflicts in multiple files with GitHub

This is an exact repeat of what we did in the last section (Appendix F.1), this time we’re going to do it from within GitHub.

Open the lab-01-website repository, there is currently only one branch, the master branch, it should look like this:

F.2.1 Creating multiple conflicts in GitHub

First create the d09-modification branch by clicking the branch dropdown and typing the new d09-modification name:

Figure F.24 - Create the d09-modifications branch

Make sure you are on the new d09-modification branch:

Figure F.25 - Switch to the d09-modifications branch

Now edit style.css, 01-intro.htm and 03-contact.html just as we did in Code F.6, Code F.7 and Code F.8 (see § 9.3.4 for details of editing a file in GitHub); style.css first.

To edit style.css, click the 11-resources folder to open it (highlighted):

Next click the 01-css folder to get to style.css. Click style.css to open it. It will look like this:

Click the pencil at the top to edit it and make the same changes we did in the previous section (Code F.6).

You can see the changes highlighted in Figure F.28.

Next enter a commit message (highlighted) and press the commit changes button.

Go back to the lab-01-website level (click lab-01-website at the top of the page) and make the changes to 01-intro.html and 03-contact.html, these are the same changes listed in Code F.7 and Code F.8; I won’t go through it, it’s the same process we used for style.css (you just don’t need to drill down through the folders).

When you’ve made all the changes on the d09-modifications branch, switch back to the master branch and make the same changes to style.css and 01-intro.html that we made in the previous section (Code F.9 and Code 10). Again, I’m not going to go through it, it’s just the same as we did for the d09-modifications branch above.

F.2.2 Merging multiple conflicts in GitHub

At this point if we try to merge d09-modifications back into the master branch we will have the following situation (this is exactly what we had with Brackets in the previous section):

Two conflicting changes to style.css giving multiple conflicts in the same file
A single conflicting change to 01-intro.html giving an additional conflict in another file
A non-conflicting change in 03-contact.html to demonstrate how this is handled at the same time

Make sure you are on the master branch; it will look something like this:

Figure F.29 - Master branch, ready to merge

Click the new pull request button (highlighted) to start the merge process. I’ve shown the result in the next figure (I’ve just shown the first part of it):

Figure F.30 - Master branch, ready to merge

The first thing to note is the ✖ Can’t automatically merge message at the top, this was to be expected, we’ve just spent ages setting up the conflicts.

The next thing is it’s telling us we can still create the pull request, and this is what we want to do.

Below this it displays the changes in each of the files (I’ve not shown all of it in the figure). This is just for information; you can’t change anything at this stage.

So let’s carry on and make the pull request, click the green create pull request button. It automatically opens the pull request page:

It is showing the branch with conflicts (middle bit next to the symbol) and telling us which files are affected 01-intro.html and style.css, note it’s not listing 03-contacts.html, it’s happy with that one (this is because the change in that file didn’t have a conflict).

The thing to do now is resolve the conflicts by clicking the resolve conflicts button (highlighted). It gives you this:

Figure F.32 - Resolve conflicts 01-intro.html

The files with problems are listed in the column on the left (two files in this case), just click the file to open it in the main window. Figure F.32 is showing 01-intro.html.

This is a bit clearer than it was in Brackets; the conflict is highlighted with the red lines and the yellow shading, GitHub will clearly highlight all the conflicts wherever they occur (unlike Brackets where you have to search for them) even in comments.

Clicking style.css in the left column gives Figure F.33, the two conflicts can be clearly seen.

Figure F.33 - Resolve conflicts style.css

These files are also editable at this point; it’s what GitHub wants us to do. Resolve the conflicts by changing the files how you like. I made the following changes:

and

GitHub puts a green tick next to the file when the conflicts have been.

The next thing is to merge the resolved conflicts, click the green commit merge button. This re-opens the pull request page, but it now shows that the merge can take place:

Figure F.36 - Pull request with resolved conflicts

Nearly there — click the merge pull request button:

This is just asking for a commit message, it puts in the default merge pull request message, change it if you want and add any other message in the box. Now press confirm merge to merge the changes and we’re there.

One more screen showing the successful merge:

Figure F.38 - Pull request with resolved conflicts

And that’s it.

In the paper copy of this website (I wrote it in Word), this is page 500. I think that’s a good place to stop.