Another day passed, and I am happy it didn't go waste. I was able to add 2 new features, although minor, to the commandline tool I've been working on since the beginning of my Fall term at school.
The purpose was to practice git merge command as part of the weekly lab of my course OSD600.
Picking Features 🤖
As the first step of the process, we had to pick 2 features to add to our project. And I chose to add the following:
1. Adding an optional -l, --lang flag: to indicate the language to use when generating the lang attribute on the root element. For example, --lang fr would mean that the HTML documents are in French, and would include , while -l pt-BR would mean the text is using Brazilian Portuguese. By default, use en-CA for Canadian English.
2. Exit with valid error codes: Exiting with meaningful error codes is a crucial part of any application as it efficiently communicates with the user if there was any problems encountered during the execution, and if yes, what kind. Since the project is still in early stage of development and the scope is small, a basic error code scheme would be enough. If there are no errors, exit with 0. Otherwise, exit with a -1. I'll try to have more complex error codes later on in the development process.
Creating issues and topic branches 🌳
After I finalized the features I was going to implement, it was time to open the issues. I opened one for each on the repo:
and a topic branch for both issues
Implementing features 💻
I would say this was the easiest part as the features I chose were super simple and hardly took 15 minutes (with testing) to implement. All I had to do was write a few lines of code by switching to the specific topic branches one at a time.
Experience with merges 🐱👤
I've been using git for quite a while now, ever since I started my coop as an Angular developer. As I continue working at the same place, I have to use different types of git commands every week.
And it gets really interesting sometimes when you are asked to work on a special feature and not merge to the common develop branch before you're confident about it. The usual way is to just branch off of the main branch (develop in this case), keep working on it and don't merge until done.
However, there have been instances where the features are so complicated and large in scope that multiple developers have to collaborate. In those cases, we used to create a common branch for everyone, that was itself based on the develop branch. And from that common branch, everyone used to branch off into their own branches that they used to implement parts of the major feature. We used to treat that common branch like the usual main branch, merge bite-sized commits to that frequently. And when the entire feature was built, the common branch was merged to the develop branch shared by all developers.
These experiences helped me appreciate the existence of git even more, as I realized the beauty and power of the features that it provides for collaborative development.
Time for the merge 🎆
Alright, time to get back to the topic. Now that I had finished working on the features themselves, it was time to merge to the master branch.
I know everyone is opting to use the name main instead of master now, but I am so used to the original name, that I don't want to let it go.
For me,
If there's no master, its a disaster.
The merges
The first merge that I performed was issue-8 into master. It was a simple 2-way merge as the HEAD of master served as the common ancestor to both branches, also known as a fast-forward merge.
The second merge from issue-9 into master wasn't as smooth for it was a 3-way merge and there were minor merge conflicts. In this case, the HEAD of master had moved by the number of commits added to it in the first merge. Therefore, the HEADs of both branches had to be compared to their common ancestor (the HEAD of master before first merge), hence the name 3-way merge.
Here's what the entire process looked like:
Leading to the following history of master:
Note: The ones with verified label are direct commits to master.
Conclusion 📖
Even though, I already had a general understanding of how merges work in git, I learned two new terms - Two-way merge and Three-way merge.
The following article gives a very brief overview of their definitions:
https://medium.com/@koteswar.meesala/git-fast-forward-merge-vs-three-way-merge-8591434dd350
Top comments (0)