I want to add a new 02-about.html page. Switch back to the master branch, create a new branch dev-02-about and switch to this new branch.
Now we have Figure 2.16:
Figure 2.16 A third branch
2
To demonstrate merging changes let’s add another page to the lab-01-website. The master branch still has the latest version of the deployable code (although dev-01-intro is more advanced than the master branch, it is under development—new branches should always be based on the latest deployable code).
I want to add a new 02-about.html page. Switch back to the master branch, create a new branch dev-02-about and switch to this new branch.
Now we have Figure 2.16:
Figure 2.16 A third branch
This one’s yellow (Circle Line—to go with Central and Victoria†1). The head is now on dev-02-about, but is pointing to the last commit on master [88934e8].
| †1 | For anyone not from England, these are tube lines on the London Underground railway. It has an iconic map originally created by Mr Harry Beck, have a look here. This was the original. | ||
Time for another file let’s add 02-about.html in the root folder (same place as index.html) and add the following code to it:
<html lang="en"> <!-- Declare language --> <head> <!-- Start of head section --> <meta charset="utf-8"> <!-- Use Unicode character 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 2.5 dev-02-about branch — create new file: 02-about.html |
Add and commit the changes with the commit message New page 02-about.html added. In my case it is commit number [decb633].
Now we have Figure 2.17:
Figure 2.17 Second new branch with first commit
Now switch to dev-01-intro (our first branch) and change the style.css file:
* {
margin: 0;
padding: 0;
box-sizing: border-box;
position: relative;
}
html {
background-color: #fbfaf6; /* Set cream page bkgrd */
color: #404030;
font-family: serif;
font-size: 26px;
text-rendering: optimizeLegibility;
}
body {
max-width: 1276px;
margin: 0 auto;
background-color: #fff; /* make content area bkgrd 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: #4F81BD; }
.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 2.6 style.css modified in dev-01-intro |
I’ve changed the colour of the h3 element; it’s blue like the Victoria Line. I’ve done this by modifying line 30; I’ve added a colour declaration:
h3 { font-size: 2.5rem; color: #4F81BD; }
It makes the page look like this if you’re interested:
Figure 2.18 01-intro.html page
Let’s commit the change with message style.css — h3 colour changed to blue. This gives me commit [6454cdc]. The London underground now looks like this:
Figure 2.19 Second commit on dev-01-intro
Let’s say that’s it for dev-01-intro, we’re happy with it and we want to deploy it, this means merging it back into the master branch. I want to do what is shown in Figure 2.20.
I want to put the two commits on the dev-01-intro branch onto the master branch.
Figure 2.20 Merging one branch into another
And we can, we do it by changing to the branch that we want to receive the changes (the target branch), in this case it is the master branch. Then we use the merge command to bring in the changes from the source branch.
This automatically creates a merge commit; this is just another commit with the message Merge branch <branch-name> in our case it is Merge branch dev-01-intro. The merge commit is [e659dad].
What we end up with is this:
Figure 2.21 Merge result
The dev-01-intro branch is still there, but all its changes are now incorporated on to the master branch. We no longer need the dev-01-intro branch so we can delete it. This is always the best thing to do with a merged branch.
Figure 2.22 Remove empty branch
Nearly done.
Finally, let’s merge the dev-02-about branch, but first let’s create a conflict situation.
Switch to the dev-02-about branch and modify the style.css file, this time we’re going to modify exactly the same line as we did with the last change to dev-01-intro. But this time, we’ll make the h3 element red.
* {
margin: 0;
padding: 0;
box-sizing: border-box;
position: relative;
}
html {
background-color: #fbfaf6; /* Set cream page bkgrd */
color: #404030;
font-family: serif;
font-size: 26px;
text-rendering: optimizeLegibility;
}
body {
max-width: 1276px;
margin: 0 auto;
background-color: #fff; /* make content area bkgrd 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: #c0504d; }
.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 2.7 conflicting modification to style.css |
Again this is a modification to line 30:
h3 { font-size: 2.5rem; color: #c0504d; }
This will conflict with line 30 on the master branch, this has:
h3 { font-size: 2.5rem; color: #4F81BD; }
The dev-02-about modification makes the 02-about page look like this:
Figure 2.23 02-about.html page
Let’s commit the change with message style.css — h3 colour changed to red. This gives me commit [ce1e15a]. The branches now look like this:
Figure 2.24 Second commit on dev-02-about
Now switch to the master branch and merge in the changes on dev-02-about.
This time when we try to merge, Git tells us there is a conflict and shows the two conflicting lines. Git is asking us to make a decision; it can’t decide for itself what to do.
We need to choose what we want to do, we can accept the master version, the dev-02-about version or we can choose to do something entirely different—we can also choose to abort the merge and think about things a bit longer.
In this case I’m going to choose the master version (the blue one). I do this by modifying the style.css file and committing the change. This will accept my resolution of the conflict and attach the commit message:
Merge branch 'dev-02-about'
# Conflicts:
# 11-resources/01-css/style.css
The commit for this merge is [5c9e772]. Our branches now look like this:
Figure 2.25 Merging the second branch after conflict resolution
Finally, the last thing to do is delete the empty branch. This just leaves the master branch with all the commits merged onto it. Like this Figure 2.26
Figure 2.26 Final arrangement, all merged back to master branch
All the commits from the two branches that were created are now merged onto the master branch line.
In section 6 I go through this exact same operation using the Brackets-Git extension from within the Brackets text editor.
tend to use a simple branching workflow (it is suitable for small teams). It is as follows:
I only have one main branch, the master branch. The master branch only ever contains deployable code. If development work takes place (for example developing a new web page) this always happens on a separate branch taken from the most recent commit point on the master branch (as we did with dev-01-intro and dev-02-about) in the previous examples. When work on a branch is complete and tested, the commits on that branch are merged back on to the master branch and the development branch is deleted.
Only merge complete and tested work back onto the master branch.
Each development branch must have a precise and limited scope (a single web page for example). It is better to have many branches each being limited to a particular topic rather than a single branch doing lots of things.
On any branch commit your work frequently and at any stage of development (even if it is a commit just because it’s the end of the day and you’re going home).
appendix b has more details on how to manage this type of workflow and how to semantically name branches and tags for commit points.
