This week my job was to to implement two new features for explainer.js and learn how ff-merge and the three-way recursive merge works.

New features

Implementing new features were pretty simple. First was adding support for the ability to refer to directory path on top of files as well. so we can now do this.

node index.js examples/

now you can get help with all three files at once instead of typing out all three one by one

Next feature was exiting with proper code. If everything is good exit with code 0, if there's an error exit with 1. Since, my application has one exit only so this part was pretty easy.

NO PRS!!!

To implement this feature we were told we cannot make any PR. We are supposed to files issues on github, create branch locally work, merge to main and then push and then manually close the issues. So that we can ss how the ff-merge and the three-way recursive merge works. And on this part I spent more time than working on the issues themselves. Because if you take a look at the main branch of my PR, you can see its a pretty linear history (or at least it was until now). It is something I learned at my co-op where we only do squash merge on main, after merging main on the feature branch, to keep the main branch history clean (also OCD friendly!). So this doing commit this way kinda hurt my soul cause now my history is NOT linear.

My initial plan was to do a --squash merge to keep the linear history intact. But after the first ff-merge, second squash merge would not explicity say it was a three-way recursive merge on the console. Although I think it does do a recursive merge since that is the default.

So, after spending more time on this than I needed to and some hard reset force push later, I did it the way it was instructed. And as expected the console had the expected output first one was ff-merge and the second one was a three-way recursive merge with NO CONFLICTS! Although not a fan of how the history looks right now (might just rebase it in the future).

For the future

I'm not new to git, I've been using it for a while now. And one thing I learned is that you don't want conflicts? don't work on the same file at once, at least on the same line. This is not realistic at all so there are once in a blue moon when merging main on your branch before merging on main, you will have a merge conflicts. When that happens open vscode and talk to the dev who recently made changes to the file and resolve the conflicts. Other than that git is pretty smart about keeping conflicts from happening. If you are lucky git will automatically do a ff-merge. If not, you better hope the conflict hunks are small and the other dev is on call or you remember what you did.