Week 3 CST 438
Describe what are the good points about using Git for source code management. What are possible problems that Git merge does not solve when merging code from different developers?
This week for CST438 we shifted our focus to version control and learned about source code management using Git and Github. I've had previous experiences with managing projects in past courses and having to utilize pull requests to properly merge different group member's development branches. Although we didn't really go into depth about the code review sections, and heavily relied on the pull request's displaying a no merge conflicts button and just continuing to merge. I am currently using it a lot in my mentorship with LibreOffice and past service learning projects, though LibreOffice utilized Gerrit rather than GitHub.
The good points about using Git for source code management is the fact that it can track and maintain a sequence of snapshots in a repository. For example every time we initiate a git commit, a snapshot of the file changes is created. If we make a mistake in the branch we had made a commit in, then we can rollback or revert it so that we can go back to the older commit that was previously in a working state. Something that correlates with this idea is also Git's branch management system. Each developer can maintain their own branch or independent versions of a project such as in our lab exercise with the dev1 and dev2 repositories pushing and merging to the main branch. Each developer can work independently creating a new feature or going back to fix a bug without interfering with the main branch code. Additionally I think having the commit messages allows for good organization and documentation of what changes have been made to the code, and allows for easier identification when looking back at the git log commit history and/or branches. A bit out of context but I have thought the integration of the source control in VS Code is quite intuitive because of the visual diagram of the branches demonstrating the merges, commits, and head. Also, it allows initiating the git commands in an interface rather than through a terminal. Though I would say terminal git commands are more practical and commonly used when the interface is not around, so it would be best to focus on those instead.
A problem that Git merge does not solve when merging code from different developers is the possibility that Developer A renames a certain variable in their branch, and Developer B modifies a section of the code where that variable is being used with the previous variable's name. The merge will happen but it may break the code because now there's a mismatched variable name and usage. Another problem that Git merge may not solve is the common merge conflict such as when two developers may develop an identical feature by changing the same lines of code. When we initiate the merge, git halts the merge then a merge conflict occurs. The developers have to manually review the code to see which feature they would like to utilize in order for the merge to be finalized. Lastly in a similar case, what if developer A removes a file and developer B modifies the same file, the merge will be conflicted since it does not know if it should keep the edited file or delete the file. Most merge conflicts seem to require manual reviews and human judgement from developers to understand what piece of code is prioritized.
This week for CST438 we shifted our focus to version control and learned about source code management using Git and Github. I've had previous experiences with managing projects in past courses and having to utilize pull requests to properly merge different group member's development branches. Although we didn't really go into depth about the code review sections, and heavily relied on the pull request's displaying a no merge conflicts button and just continuing to merge. I am currently using it a lot in my mentorship with LibreOffice and past service learning projects, though LibreOffice utilized Gerrit rather than GitHub.
The good points about using Git for source code management is the fact that it can track and maintain a sequence of snapshots in a repository. For example every time we initiate a git commit, a snapshot of the file changes is created. If we make a mistake in the branch we had made a commit in, then we can rollback or revert it so that we can go back to the older commit that was previously in a working state. Something that correlates with this idea is also Git's branch management system. Each developer can maintain their own branch or independent versions of a project such as in our lab exercise with the dev1 and dev2 repositories pushing and merging to the main branch. Each developer can work independently creating a new feature or going back to fix a bug without interfering with the main branch code. Additionally I think having the commit messages allows for good organization and documentation of what changes have been made to the code, and allows for easier identification when looking back at the git log commit history and/or branches. A bit out of context but I have thought the integration of the source control in VS Code is quite intuitive because of the visual diagram of the branches demonstrating the merges, commits, and head. Also, it allows initiating the git commands in an interface rather than through a terminal. Though I would say terminal git commands are more practical and commonly used when the interface is not around, so it would be best to focus on those instead.
A problem that Git merge does not solve when merging code from different developers is the possibility that Developer A renames a certain variable in their branch, and Developer B modifies a section of the code where that variable is being used with the previous variable's name. The merge will happen but it may break the code because now there's a mismatched variable name and usage. Another problem that Git merge may not solve is the common merge conflict such as when two developers may develop an identical feature by changing the same lines of code. When we initiate the merge, git halts the merge then a merge conflict occurs. The developers have to manually review the code to see which feature they would like to utilize in order for the merge to be finalized. Lastly in a similar case, what if developer A removes a file and developer B modifies the same file, the merge will be conflicted since it does not know if it should keep the edited file or delete the file. Most merge conflicts seem to require manual reviews and human judgement from developers to understand what piece of code is prioritized.
Comments
Post a Comment