Description
This post is about lab 05 for OSD600 course at seneca college.
This week, the students are required to learn and practice git rebase
and git commit --amend
. First we were required to refactor our code and make a commit for each refactoring. After finishing all the refactoring, we were to rebase the commits with main branch, and squash all the commits made while refactoring into one commit. Finally, we amend the final commit.
Process of Refactoring
Goal
For this refactoring, what I focused most on the SOC(Seperation of Concern). Second, I focused on encapsulation.
Steps
Loading
.codemage-config.toml
file from home directory was called twice in different files. I thought that this is really inefficient. So I tried to make it called only once.I had total 4 files: main(
codeMage.py
,api.py
,translator.py
,loadConfig.py
). Most of the files had only one function. The function had all the logics to do a task. For example,translate()
function had all the logics for verifying target language and source language, deciding output file name, and calling api function. Readability was disastrous. What I did first was encapsulating the function and some variables as a class and made some of the variables as class attributes and created private methods for other logics such as veryingtraget_language
or gettingoutput_filename
. As as result,translate()
only contains the necessary logic for callingllm_api
.Likewise, I made a class for
call_api()
function, which is located inapi.py
file. I also made class attributes forapi_url
,api_model
, andapi_key
. I focused thecall_api()
method on creatingClient
request and receivingCompletion
response.
Things that were challenging
The thing that I was most afraid of was breaking the code. At least it was working well if the code was somewhat dirty. Therefore, I made a new branch and tried to make as small changes as I can. And also, I didn't delete the previous code; I just made commented them out. Only after I made sure the refactored code works fine, did I deleted the code.
Thoughts on Rebase
Maybe I am wrong; however, I think Rebase is not a new thing. It's just a reverse version of three way merge. Three way merge
is, merging the issue branch into the main branch; on the other hand, rebase
is bringing the main branch on the bottom of the issue branch. Things that happen while performing rebase
is basically the same with what happens while doing three way merge
. If there is conflicts, you need to solve it, and if not, they are just smoothly combined. In conclusion, rebase
is sort of a trick. In a simple way, merge is putting your new commit into the middle of main branch commits(it could be top), and rebase is putting your new commit on top of the main branch commits.
Plan for Rebase Experiment
c1, c2, c3, c4, c5, c6 - main branch
c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 - new issue branch
In this lab, what we have done is squashing c7~c10 based on c6 commit, and then make it look like:
c1, c2, c3, c4, c5, c6, c11.
However, I wonder if the follwing is possible.
c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 - main branch
From here, I checkout a new branch with c6 commit.
Then the new branch will be:
c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 - main branch
c1, c2, c3, c4, c5, c6 - new branch
And first I squash the commits c4, c5, c6
the new branch would look like:
c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 - main branch
c1, c2, c3, c11. - new branch
Then, Cherry-pick the c7, c8, c9, c10 from main branch into the new branch. Or if possible, rebasing the main branch onto the new branch(probably I may need to do drop commits
).
If this works, it would look like:
c1, c2, c3, c11, c7, c8, c9, c10 - new branch
However, I have no idea if it would work, but it looks like an interesting experiment.
If I succeed in doing this, I think I would feel like I am the master of space and time in git.
Top comments (0)