Git for PHP developers [merging]

Coding (Php 7.x)


Discover how to merge branches on your application and what tool you to use
 
/img/blog/git-for-php-developers-merge-branches.jpg

One of the most important tools that you will use in your web development career, independently of the language you choose, is Git.

 

Git has allowed web developers all around the globe to create application while making it easier to fix bugs and keeping projects on the right path.

 

That is not an easy task, and to do so it has implemented several features that are not straightforward to understand.

 

One of this feature is surely merging.

 

The git merge command allows you to integrate the updated code within a branch into another branch.

 

Git merge is used in conjunction with git checkout because, as you can see below, you need to freely move to and from the branches you have.

 

The series

 

Git for PHP developer is a series realized for the web developer that wants to start using tools to increase their productivity.

 

This is the third chapter of the series.

 

If you missed it, you can have a look at the previous episode of the series Git for PHP developer at the link below:

 

 

 

 

 

Merging

 

By now you should be already able to create a repo from a directory and create/delete branches with different code on them.

 

In this article, we’ll see how to put this different code together in order to create a reliable application.

 

Merge

 

To start with, the concept here is very easy,

 

We do not want to work on the master branch because we know that it is much better (and safe) to fork the code on a branch and work from there.

 

If the code we develop has some bugs, the feature is not needed anymore or we just do not like what we did we can simply remove the branch and the master code won’t be affected at all.

 

That the beauty of working with branches in Git.

 

You might have thought:

 

But if we work on a branch different to the master, how do we see our updates on our application?

 

Here is the solution.

 

The way GIT works is to combine (merge) several sequences of commits into one git-flow.

 

GIT uses one commit for each of the two branches, and by merging it git will try to get the middle ground among the two files.

 

If the merge has happened without issues the result will be a new commit in the branch that received the external updates otherwise we will have the so-called conflicts.

 

I’ll show below an easy way to solve them.

 

Show me the command!

 

Yes, finally the interesting part.

 

First things first, to merge two branches together we need the two branches.

 

As we have learned from the previous articles we can obtain a new branch using the command checkout -b

 

# Start a new feature
git checkout -b externalBranch master

 

Of course to create another valid branch that makes sense we have to update it with some new code and add it into our GIT environment.

 

Let’s pretend I have updated some lines in my index.php file
 

git add index.php
git commit -m "Updated some lines"

We added the commit and we are now ready to merge.

 

The way it works is really simple.

 

In simple words we need to be in the branch we want to receive the update and then include the external branch.


 

git checkout master
git merge externalBranch 

 

To work in the cleanest way possible it is always advised to delete unutilized branches.

 

We can easily do that with the command

 

git branch -d externalBranch 

 

That’s was a piece of cake!

 

Now, things do not always go so smooth and we must consider that we have a different way to merge our updates too,

 

They depend mainly on what is the situation of the branches, also how big is the project and how often it is the master branch updated.

 

 

Fast Forward Merge

 

 

This is the easiest to understand and the one that will occur more often if you are working alone or in a small team.

 

This happens when the updates form the master to the tip of the feature branch are written linearly.

 

In this case what GIT does just consist in moving the HEAD into the last commit that in this case would be one of the new branches, hence the merge.

 

This quick movement of the master from its original position to the last commit of the history is the reason this technique is called fast forward.

 

You can find more about fast forward merge here

 

 

3-way merge

 

Of course, nothing is always all fun and games,

 

In case we have a team of several developers is common that while you are working on a feature someone else merges one or more branches that contain updates on a file you are working on.

 

If that the case we just lost our linearity,

 

Do not worry.

 

In this case, the solution is a 3-way merge.

 

What happens in a 3-way merge is that, since the two branches are not on the same line, both the branches move forward.

 

They merge into a new commit that is one step in front of both of the latest of the two branches

 

 

Conflicts

 

In the previous paragraphs, we saw what happen when one or a few developers work on the same project at the same time.

 

The ways the merges occur depends on the current status of the different branches.

 

What if instead of updating the master branch two or more developer update the same file?

 

As you can imagine, GIT is able to spot if a file has been modified and cannot merge because of a conflict with the current file.


 

On branch master
Unmerged paths:
(use "git add/rm ..." as appropriate to mark resolution)
both modified: index.php

 

In the example above we just tried to merge two branches and GIT prompts a message that indicates that there is a conflict on the index.php page.

 

GIT is not only able to find a conflict but it actually modifies the content of the file by adding signalling mark to show where the conflict occurs.

 

<<<<<<< master
this is code from master
=======
this is code from the feature branch
>>>>>>> 

The minor and major symbols act as markers to show where the conflict starts and finish whereas the equals symbol represent a separation between the two versions of the conflict.

 

The first is the old content of the file whereas the second part after the equal signs is the code that comes from the branch we are merging from.

 

I believe, as several dozens of web developer, that managing conflict is the most annoying part of working with GIT.

 

The good news is that there are several techniques like the ones described by Geshan Manandhar in his article 3 simple rules for less or no git conflicts or tools like the one we are going to see on the next section

 

 

become a Patron!

 

 

Difftool & Mergetool

 

The most common command to manage conflict or when you want to check what content has been modified in your web application is git diff.

 

This command shows line by line all the rows in your files,

 

If a line has been added from the original state of the page GIT prepend the line with a plus in case a line has been removed it prepend the line with a minus sign.

 

Using the terminal, in this case, is not always the best solution.

 

Just thing at a commit in which you edit a dozen of files or hundreds of line of code.

 

Finding errors successfully among all these updates from a tab in the terminal is not an easy task.

 

For these reasons, web developers have come up with a solution and use external software to manage this issue.

 

One of the most famous software you can use in this case is Diffmerge.

 

It is quite simple to configure and after you have done it you would be able to use it when you run the commands difftool and mergetool.

 

The two commands provide a really similar feature because both of them show the differences in codes among two different branches.

 

The command difftool works like git diff, but as discussed automatically open the software you have chosen as a tool and compare the two version with a left and a right pane, making it way easier to understand what is going on.

 

The command mergetool is a bit different because it works specifically in case we are merging two branches.

 

it is amazing in case of conflicts.

 

Inside the software is represented by three panels,

 

One for the branch that is going to be merged into, 

 

Another for the branch that contains the code that will be merged.

 

And in between, the result from GIT calculus to merge the two version of the file together.

 

Even though this is a good tool I always recommend to use extreme care when dealing with conflicts.

 

It is very easy to break an application by making a small mistake in this phase.

 

Conclusion

 

If you are learning how to use GIT you got to learn how to merge properly two branches.

 

Version control is one skill that nowadays is absolutely required if you want to become a professional in the web development field.

 

Even if you are already an experienced web developer, GIT is a topic so wide that there is always something new to learn about it.

 

Where you can go from here?

 

This is the third part of the series, in you have missed you can check the first episode of GIT for PHP developers.

 

Otherwise, you can make your hands dirty with some PHP code by brushing up PHP

 
 
If you like this content and you are hungry for some more join the Facebook's community in which we share info and news just like this one!

Other posts that might interest you

Coding (Php 7.x) Mar 20, 2020

Git for PHP developers [branches]

See details
Coding (Php 7.x) Apr 13, 2020

Git for PHP developers [sync]

See details
Coding (Php 7.x) Apr 30, 2020

Builder in PHP [Design pattern with examples]

See details
Get my free books' review to improve your skill now!
I'll do myself