CST438 - Module 3

What did I learn in the third week of CST438?

Working through lab 5 and setting up the GitHub organization and project for assignment 1, showcased how much Git can organize a team workflow. Basically, branches allow developers to isolate code to do work independently from main, making it so that any changes don't apply to main and can be merged through a pull request, which allows for a code review before a merge process is initiated. For example, during the two-developer simulation in lab 5, two branches working on the same file were to be merged, the first branch was successful, while the second branch wasn't and required a refactor to resolve merging issues, showcasing local repositories on their own machine, independent commits, code review, and syncing when they are pushed/merged into main, showing real VCS. Furthermore, merge conflicts are very straightforward to resolve, and can be shown through a code review that specifies approval or required actions that can then be resolved by the initiator of the pull request, which is then documented within Github's history through commits on what was done and who did it.

As for inherent problems within Git merge, that the assignment 1 doc pointed out, is that git merge can only resolve or prevent line-level conflicts. Therefore, if two developers edit different lines that can merge cleanly to main, it can still fail to compile, which normally is due to renaming something within another file ending up with old and new naming conventions. In the end, in order to catch and resolve these inherent issues dealing with semantic or logical bugs, a team would need to run unit and selenium system tests to resolve any problems that could trickle through.