“I began using Git as soon as I started learning Java; I know from the jump that utilizing source control tools would be just as crucial as knowing how to program” – no one ever.

I wish I knew how valuable tools like Git would be before I began work at my first job. I started learning Git at IBM. They were in the process of switching from an SVN repository to a Git repository so thankfully even the most experienced employees around me were a bit out of their comfort zone. I learned to use Git through the command line before I realized how seamlessly it integrates with Eclipse. Thankfully my Git command line skills still came in handy for updating remote servers and writing automation setup scripts. At The Learning Bar, I also used Git regularly during my time as a Web Developer, and when performing scrum master duties in my role as a Business Systems Analyst.

One of the exciting things that I realized as I gained more exposure to git repositories was how differently two teams could choose to interact with Git. I have worked on larger projects which had to maintain multiple separate versions concurrently, and less complicated projects where only the most recent version was available to customers. The main difference between how these projects interact with Git was branching versus forking. My experience working with both strategies has helped me better understand the pros and cons of each.

Over the years, I’ve found that as soon as a project involves two people using Git isn’t an option anymore; it’s an obligation. Today I usually find myself relying mostly on using git through my IDE due to the convenience, but I can also use the command line when required. Whatever the mechanism, I can fulfil my obligation as a developer to be able to collaborate with team members through Git.