Working on parallel branches.

“Fast-forward” and “three-way recursive”.

This post covers my approach working on parallel git branches in URLpilgrim repo.

Before the beginning.

Professor Humphrey(David Humphrey) had given me good feedback about URLpilgrim, and I knew I would have to do some refactoring before diving into parallels branches.
So URLpilgrim was revised and refactored. The code becomes easier to understand; the program is faster than never, but not ready for a new release yet. I’m very excited about the future release.

Now back to git branches.

Humphrey told us to pick up at least two features of his features list to add to our release 0.1 (in my case URLpilgrim). Then open an issue on our repos for each chosen feature, create a new branch for each issue, developer the features and then merge the branches. The idea is to learn fast-forward(git merge the branches by itself), and three-way recursive(git will ask you to solve conflicts between branches) merge.

Once you created two branches from your master branch simultaneously, when you start to write new code into them, they begin to grow in parallel to your master and are also different from each other, which means that the first branch merge probably will be a fast-forward merge and the second branch merge probably will be a three-way recursive merge.

After picking up two features to add, I made a mistake: instead of creating two branches at the same time, I made one for the first feature, developed the feature and merge it, which means that I would not experience a three-way recursive merge in the next one. So I had to pick up another one and then proceed as requested.

After merging all the features, I had to insert one feature again because I made some mistakes when merging.

We following learn more about how to use git.
Let’s keep walking.
Cheers.
Pedro