Merging and Rebasing

I remember sitting in our Engineering Design Studio back at the Abu Dhabi campus with @woswos, first learning to use GitHub beyond the normal fetch and push commands. We were quite excited to learn that GitHub provided a lot more tools than just the core git, like being able to manage projects with a Kanban board and set-up wiki pages.

We were also learning to explore branches a bit. It was a little daunting, but we really wanted to learn the proper conventions and the “right” way of going about it. So, we created a “dev” branch for a project we were working on and told ourselves that we would push commits to this dev branch and only merge it with the master when we were certain that our code was stable.

Going through this lecture, it was a nice memory to think back to, because it led me to realize the progress I was making and how it was now less scary to approach the topic.

Prior to this lecture, I had some experience with git merging, as well as resolving merge conflicts. However, I had never done, or was aware of, rebasing. The graphic below helped me visualize what the point of using rebase would be:

I would be lying if I said I fully understand how I’d go about implementing it. Looking through the lecture slides, it seems that there is a lot of room for error, and it is especially scary to think that you can rebase the other way around and have the master commits be on the tip of your feature branch. I think I would probably (very religiously) follow the advice:

Before you run git rebase, always ask yourself, “Is anyone else looking at this branch?” If the answer is yes, do not rebase.

Group Projects

I had initially laid my eyes on Pytorch3D, but in the previous blog post explained why I was not so keen on it anymore. This time around we were able to (in our Zoom clusters) have a group meeting about the projects that we were interested in. We definitely leaned towards working on Lemmy and were able to get a project evaluation started for ourselves, just so we could get a rough idea on whether this project was feasible. We concluded that it was a relatively active project with quite a few elements we were excited to learn about. We were able to come up with a meeting time for our group (right after class). There was also some fantastic labeling going on with the issues and we even peeped a “good first issue” tag, which is encouraging.