Link to My Repo
Link to Issue 10
Link to Issue 11
Link to First Merge Commit
Link to Second Merge Commit
Description of Lab 03
In this week's lab, I learned about how to merge branches. The task was to implement a feature and fix a but on each different branch and then, merging those branches into main branch.
Process
I thought about what feature I would like to implement, and what bugs my tool has. The first thing I did was testing my tool with all the options that I implemented and testing it with all edge cases that I can think of. And I found a bug that print out token-usage info onto stdout even when the flag was not on. Therefore I decided to create an issue to handle this bug. I also thought that it would be really interesting if my tool streams out the output onto stdout in a real time instead of waiting all the response from API and dump them out at once. So I decided to create another issue for implementing -s, --stream feature.
I created two issues for those problmes and then, I made two new branch to solve Issue 10 and Issue 11 on my local machine. After I implemented my code and fixed bugs, I merged them. When I merged the first branch, it was merged without any conflict, which is fast-forward merge. Then, when I merged the second branch, it gave me a warning. I had to solve the confilct. I had a small issue here. I could find the buttons or options that I saw in the lecture of professor such as reslove in Merge Editor. All I coud do was just accepting incoming chagnes. I think maybe it was just because there was no conflict to solve. There was just one different line. As a result, if I don't accept it, then it will be no merge. Anyway, I merged the second branch into my main branch. It looks like this in the app Sourcetree
This is a visualized history of commits and branches for my repo. What was interesting and awesome about merging in git hub was that when I merged the second branch(it has no code for -s, --stream feature), I didn't make any conflict or warning, git just knew that the unknown code (to the second branch) was not a problem, and it only warned about the code that conflicting part (new code from second branch) that was really amazing.
I just asked ChatGPT, and it says
Since the code added to main from the fast-forward merges didn’t overlap
with the code in the issue11-fix-stderr branch, there were no
conflicts, and Git merged them smoothly.
To sum up, the code in main branch (after fast-forward merge) didn't overlap in other parts except for the fixing bug part, it didn't generate a warning.
Reflection
From this experience, I learned that when I make a new branch for adding a new feature or fixing a bug, I should minimize the code changes since it could cause a conflict. I believe that it would be a better practice to make a small change at a time, several times than to make a huge changes at one merge or commit.
I am glad and happy that I am getting more confident with git, if little by little. Git was my nemesis. I was willfully blind to git. I sweep it under the rug. Although I knew I needed to have deeper understanding of git, I didn't and I was afraid of learning it. I didn't know where and how to start. I tried a few times to read the document and book, but I failed many times. However, from this course, I have started learnign git successfully and am getting confident with git.
Top comments (0)