In the week prior to spring break, we went over the differences between a rebase and merge in Git. However, this exploration of the differences between a rebase and merge was only a conceptual one. This week in class(Monday and Wednesday) we actually got the opportunity to practice using the commands in Git and see how the changes would be reflected in the file structure. We were split off into groups of two to three and were given a list of four exercises to complete. While ostensibly all of the exercises were trivial, they were in fact quite difficult once you actually started trying to do them. Much of this stemmed from my own unfamiliarity with Git and the command line in general. But after you expose yourself to it enough, a lot of the commands start feeling natural through rote memorization. Furthermore, Professor Joanna was very helpful when it came to roadblocks in progress, so none of my questions went unanswered.

As for the group project we were assigned to for the rest of the semester, my group and I met with each other on Friday(03/27/20). We met over Zoom and discussed ways on which we could contribute to our open source project(Tuxemon). The meeting lasted about an hour and a half and it started with a lot of logistical stuff. This included confirming every one was on the same page such as all being in the official Tuxemon discord server. This is important since most of the active contributors to the project often communicate through this chat service. They often will even directly post an issue in the discord server rather than the Github. We also made sure each of us had the correct version of the game installed since one of the ideas we discussed about contributing was finding bugs in the game itself. Then we could either raise the bug as an issue onto the Github page or try and fix it ourselves since we’re all familiar with Python. We also made a shared Google doc for each of us to type in and add contribution ideas to. We then spent the rest of the meeting time playing the game and finding bugs or possible areas to improve on. All of these ideas were then added to the shared Google doc for future use and brainstorming. We figured we’d try and play the game first and familarize ourselves with it and then build on it from there. We’d initially raise issues and then when we feel more comfortable, we’d start actually trying to fix issues and even implementing our own ideas as well.