One of the most well known features of git is the ability to carry out parallel workflows. The fact that a developer A can work on a specific part of the codebase while developer B can work on another part of the codebase and neither of them need to worry that about the other developer's existence is a killer feature, specially on an age where software development is getting more complex, and this complexity cannot be handled by a single person alone.
However, parallel workflows is not only useful on a team-based context. In a more general view, it helps to isolate the development of a feature from the rest of the project components. If I were to experiment with a wildly different idea on my project, I can easily create a new branch from the current branch and start a new development phase. After a few days, I can go back to my usual development process, by switching the branch that I was working on. The best part of this whole ordeal is that I can store everything: the changes that I did on the experimental branch, the changes I did on my work branch, as well as my main branch (the branch that contains the code that I would release after a testing period).
However, how good is this branching feature? This is what I decided to learn when working on my static site generator, yassgy, by implementing two features on different branches, parallel from each other.
yassgy is a bare-bones static site generator, that currently lacks several features, which is I decided to work on it a little bit more. This time, I added two new features, the --lang option, and the --output option.
The --lang and the --output features, summarized
The --lang and --output options are really simple.
The --lang requires the user to help yassgy mark the generated HTML documents with the proper language support. yassgy lacks the power to discover the language of the page it is reading from to generate the HTML, and will probably never implement it. The --lang will accept a string from the user, which will be used as the value for the lang attribute of the html element in the generated HTML document.
On the other hand, --output will override the directory name of the output folder. While not a big deal, since the user can issue a mv command to rename the directory, it is a very convenient feature (just like the -o feature found in the gcc compiler to name the resultant executable).
Both features have a short-hand form, that being -l for --lang, and -o for --output.
The discussion for the features
The features were first filed on a GitHub issue for documentation's sake. The issue for the --output option can be found here, while the issue for the --lang option can be found here.
Notice that these issues are not closed. The reason for that can be found in the issue thread, but as a summary, the commits that address those issues (commit for the --output option and commit for the --lang option) do not complete the whole specification of the issue, so that is why I left them open.
Experiences with branching and merging the features
Branching
I would have to admit that I was surprised at the fact that branching off to start working on a new feature or fix is rather easy. After all, git was designed with this workflow in mind, so it would be weird that the tool does not facilitate well such workflow on the first hand.
Either way, branching off to a new issue was as easy as writing a command like:
git checkout -b issue-8
This command helped to both create the branch, if non-existent, and then switch to it so I can start to work on it.
I created two branches on my local repo, issue-8 and issue-9. Both branches are named with respect to the issue they primarily address.
Amusingly enough, both issues touched on a very similar feature: command line argument parsing.
Since yassgy does not use a library to parse command line arguments as options and others, I had the task to write a very primitive parser that could group the options properly and then parse into a single command.
This meant that I had to expand the command line parser process quite significantly to be able to add two more options!
However, the current solution is not ideal, since there is a lot of repetition, and will be addressed to reduce code size and boost performance.
Either way, since both branches touched on that particular feature, this meant that I had to copy some code from one branch to the other and then do some slight changes so that I can add the feature that the issue is requesting.
I could have created a third branch that had this expansion of the command line parser, and then both branches issue-8 and issue-9 can then branch off of that branch, but it was already too late when I thought of that.
Merging
My intention was to purposefully create a merge conflict so I could deal with it at the end of the lab and learn how to deal with such conflicts.
I changed some lines of code that I knew git could not solve on its own, and effectively, it couldn't.
When I tried to merge both branches into the master branch, a merge conflict was raised. I had to modify the files that were conflicting to resolve this issue. It wasn't as simple as accepting changes from both branches, or just choose from one of them. If I had done that, I would have lost a lot of progress.
I had to reason about how to merge these two features so that they could work harmoniously in the main branch, and somehow not cause any bugs. For this reason, I am starting to understand why some projects have a dev branch...
Either way, I was able to solve the merging conflict, and you can check so by referencing this commit on my GitHub repository.
Final words
I would have to say, I am very pleased with how everything turned out for the branching and the merging exercise. It was somewhat difficult to get used to it at first, and the fact that my text editor is not configured to automatically update when the file is changed from another program was kind of jarring. However, I might have to say that I did learn a lot from this experience
Before I end this post, I would like to answer my own question,
[H]ow good is this branching feature?
Extremely good. I would recommend to leverage the branching feature to organize your development endeavors without fear of losing your main progress.
Top comments (0)