git checkout -b week1-reflection

    Well, in week 1, the Git commands were completely new to me. At first, the whole concept felt confusing and honestly kind of tedious, but after enough repetition, it starts to click and become second nature. For example, using the command "git checkout -b 'someName'" makes coding a lot safer. It creates a new branch so you’re not directly tinkering with the main branch while experimenting. Once you’re happy with your changes, you can merge them back into main without fear of breaking everything. I also didn’t know what “commits” were at first. Turns out, they’re basically little checkpoints or progress notes for your code. Each commit captures what you changed and includes a message describing what you accomplished. The command "git status" shows you what’s been modified and what’s ready for your next commit. Then, "git add ." stages everything, and "git commit -m 'your message here'" records those changes with a note about what you did.

    A few other handy commands:

• "git commit --amend" lets you tweak your most recent commit (great for fixing that embarrassing typo in your commit message). But you should only use it before pushing to GitHub, since it rewrites history.

• "git stash" is pretty clever as it lets you temporarily “stash” your unfinished work so you can switch branches without losing anything. When you’re ready, "git stash pop" brings it all back.

    There’s still a ton more Git magic for me to learn, and I’m actually looking forward to adding more tools to my version-control arsenal.

    Unit tests have also been surprisingly helpful. They keep your tests neat, organized, and in their own safe little sandbox. Back when I was learning C++ in Visual Studio, I used to test my code right in the main file with a bunch of print statements to trace what was happening (chaotic but effective). JUnit 5 feels like an upgrade. It copies over whatever methods you want to test, along with @BeforeEach and @AfterEach sections where you can set up and tear down your test data. I’d never used assertEquals or assertNotEquals before, so getting to see those in action was pretty neat.

    Interfaces are still new territory for me and, honestly, a bit weird. From what I understand, they’re like a contract: any class that “signs” the contract (implements the interface) has to provide definitions for all the methods it declares. The methods are implicitly public and abstract, and the fields are automatically public, static, and final (basically constants). It’s a new concept for sure, but I’m curious to see how it all ties together. Week 2 seems to be heading deeper into that world, so I’m ready to dive in and experiment.