For those of you who don’t know me, I’m Eric Amodio, creator of GitLens. I’m an innovator, leader, architect, and seasoned full-stack developer. I started developing GitLens way back in 2016 when I fell in love with Visual Studio Code and wanted to play with what was then newly released extension support. It all started with a simple question: could I add Git insights via CodeLens (hence GitLens) to any document? Which of course was yes, and a whole lot more.
If you’ve been building client websites for a while, you may remember a time before WordPress. A time when building websites meant creating every HTML page by hand. At some point, you probably decided that there were common features that every customer needed on their site, so you started using one customer’s website as the template for the next. Of course these days, WordPress is the underlying software for many modern websites, and there’s no need to re-invent core functionality.
If you’re writing or tracking code for a project you’ve likely heard of Version Control Systems, or VCS, also commonly referred to as source control. The primary function of a Version Control System is to host a project and track how it develops over time. With a VCS, developers can compare changes in files, track commits, propose changes, view project history, revert to old versions of the project, and more.
You groan. Perhaps not audibly, but your eyes widen and then slowly shut with dread. After a lucky streak of merging feature branches without incident, you finally hit a Git merge conflict. Unsure of where to start, you sheepishly bring up Slack and direct message a plea for help. Maybe this has been you, or maybe you’ve just seen it happen. Either way, it means spending time untangling the code by yourself, or with the sympathetic assistance of another.
