This week was a bit of everything. A bit of a Git command line lesson (but more of a refresher for me), and a lot of classmates showing off how good their JavaScript (and CSS surprisingly) skills are. It’s kinda weird to see how good my classmates’ presentation skills are (and they were probably better than mine)!

It was kind of interesting to just see how Git would be taught in the classroom, as I never really had a formal introduction to Git back in high school (when I was first introduced to Git and GitHub as a way of submitting assignments for my AP Computer Science class). I was mainly taught on how to clone a remote repo into my local machine, how to add files to the staging phase, how to write a commit message (like any Git message, and not a specially formatted one), and how to push things. Over time I kind of learned how to go out into new branches and how to jump between them, although these steps were kinda shaky since I didn’t really have to use branches a lot, and how to untrack and remove files from a Git repository (since there are times when cache files accidentally get staged because I didn’t pay enough attention to try and create a .gitignore to prevent those files from getting staged in the first place). (Also, as of late, most text editing and Git work has been done via Visual Studio Code for convenience reasons, which means I don’t really get to do all that command line exercise that comes with doing Git operations.)

I was kind of not expecting to see more advanced concepts besides fundamental Git knowledge getting used during the Git exercise this week (though it was nice to get a bit of a refresher on git branching and even merging for that (since sometimes I’ll be super lazy and just merge on)). One of the more important commands that I should’ve learned earlier on but really just learned in the Git exercises this week was git status, which is a good way of seeing which files haven’t been committed yet (or files where there might be edits that haven’t been committed yet). git diff is also pretty useful if you needed to quickly go check and see what changes were made between two commits (though it gets funky (like additions you’ve made become removals) if you do not order the two commit IDs correctly, as you should probably have the older commit ID first and then the newer commit ID).

git cat-file was another Git command that was pretty interesting. It kind of has a dual purpose of acting like an enhanced git log that also discusses about the file structure of a git commit, shows a file structure of a repo at a certain commit (like an ls for a commit), and cat to show what the file looked like at a specific commit. I feel like this is a bit tedious, as you will need to dig through multiple different trees just to see the changes you’ve made at some point (though I do feel like it might ultimately be less tedious than trying to switch between different Git commits if you kind of want to refer to the content of a file that was in a previous commit that is no longer there).

Also, I kind of didn’t know that there was a non crazy way of restoring files if you accidentally deleted (or screwed up a file too much) a file but needed it back in the form of git restore with the name of a file. I was previously aware that I could do something similar in the GUI of most popular IDEs like VSCode, but it’s pretty nice to see that I can do the same straight from the command line if I find that convenient.

One cool thing that I didn’t know until now was the fact that you can git checkout to a commit–I was always told that you only do that in the context of checking out to a different branch.

I also like the fact that you can see how different branches have been deviated and recombined onto the current branch you are in right now with the git log --graph --decorate --oneline --all (or in cases where you are only maintaining a single branch, you’ll just get a list of commits and the commit messages).

One thing that I wished was presented in the Git workshop (but thankfully was presented during Team 2’s Wednesday browser extension presentation) was how to structure commit messages such that it’s easy to understand what the purpose of the commit is, and what the change was. Team 2 decided to enforce a subset of the Conventional Commits formatting to clarify if a commit was made to fix a bug, or an enhancement. (I guess the git merge and squash would be super helpful when combined with some sort of style guide for commits.)

While I was watching the other presentations, I kind of felt that our group’s contributing guidelines were a bit lackluster, since we didn’t have much structure going on in terms of programming styles, or adding GitHub labels (like Team 7) to new pull requests and issues made on GitHub (though to be fair, the other extensions felt a bit more substantial in terms of functionality, while our extension felt more like a piece of political satire and something that might be funny for a bit, but doesn’t really feel useful in the future). I was especially surprised that Team 4 decided to implement preformatted GitHub issues (since I thought those structural things would only come on with an increasing number of people working on the project, and not when the project is at a relatively small scale that humans can easily parse through issues).

I also find it interesting that some groups enforce a no fixing an issue that you found type of policy, while others are more lax about it (which I still kind of don’t understand outside of the context for our class). I’m more of a fan of taking the initiate to fixing an issue if you can take a crack at it, but sometimes it’s better to make sure that an issue can be reproduced before trying to unnecessarily fix a manufactured issue.

As for the extensions that I saw, some of them were super goofy and crazy (like who wants an infinitely scrolling autoscroller extension), while others, like the currency converter extension, were the type of thing I wished I had back in London last semester, when I was booking flights and doing a whole bunch of other travel related planning that can only be counted as things you’d do on laptops (or something with a big screen).

booking flights on a phone is crazy. that is a laptop activity

— x (@soulohlove) April 1, 2024

A very relatable tweet, from Twitter user @soulohlove.

I also really liked the Tomato Clock idea, as it allows people to have some structure into when they’re doing work and when they can decompress from the work (and it’s kinda similar to an iOS app I made, but mine was in the context of AP Exams back in 2021 aka the cursed COVID year). I also liked the Quick Notes extension as a way of just making sure any LaTeX you write looks correct, though I wouldn’t really know how to use it because of the fact that I usually use my iPad to write notes and do handwritten homework.

Ultimately, the one big takeaway I had after seeing my group dynamics and seeing the other groups and inferring how their group dynamics went, I kind of realized that our group should have operated a bit more formally in terms of implementing a code of conduct, contributing guidelines (and styleguide, as they go hand in hand), and even on how we should delegate speaking roles. I feel like we were a bit too laissez-faire in terms of splitting up responsibility, which can work in the background (until our project gets popular and more people want to help out on the project), but works less well when we have to present in person. I really enjoyed everything that happened this week though, including the fact that we were able to do a pretty good presentation even though our group was pretty unstructured in terms of how we distributed our responsibilities.