This week we went through the process of merging different branches and generally working in parallel with different features. Explicitly performing merges was something I Was not familiar with. In most of the foss projects I have contributed on, it is pretty much a standard that your code would get into the main branch through a pull request(which, in theory is a merge on approval).
There's two small features I implemented for my project represented in the following issues:
Issue-31
issue-32
These were pretty straightforward to implement and required minimal effort on my side, perhaps the most repetitive thing done was adjusting the tests to some new members I added on the core datastructures, but aside from that It went very smooth.
The imporance of parallel branches
It is often common that as developers we have to embark on tackling multiple things at the same time when working on a project. To maximize our productivity git provides a lot of facilities, and branches would be the best abstraction for developers to utilize. Imagine in a large project, it may arise that multiple people contribute to the same file. To solve many of the changes that may arise because of this, git provides a very comprehensive conflict resolution system, which marks with separators (<<<
). After that it is up to us to represent the solution of this conflict.
Conflicts were pretty common when I was working at my Co-op at Kinaxis. Sometimes we'd have these codebase-wide changes that introduced or replaced certain data types (eg, replace int
to int64_t
). Thankfully nowadays IDE's contain amazing features to make these conflict resolution as smooth as possible.
While all of these are not new for me at all, in the lecture we had last Friday I saw some pretty useful techniques to work with branches I was not familiar with at all.
Conclusion
Working in parallel is a fundamental thing that thankfully, git abstracts for us amazingly. It also provides certain facilities to for instance duplicate branches that will allow us to further experiment and deliver better-quality code.
Some brief updates on Release 0.2
This week went amazingly in regards to the projects I'm currently contributing to. For Clangir: I'll be diving deep into this project as I was allowed to upstream the work into the main LLVM repo! -> (I'll expand on what this represents next week).
I also spent a decent chunk of my week working on IREE, and I was able to make amazing progress in one of the issues I chose with support from the maintainers. While contributing to this project wasn't very straightforward, I DID LEARN A LOT. In fact, it's a blessing that it's been this complicated. (Again I'll talk more about this next week).
Regarding my foss journey so far I can confidently say I'm helping to shape compiler infrastructure at the age of 21, which is amazing.
Top comments (0)