Git commit messages – actually, any commit messages – are one of those things that I believe start off with the best of intentions.
That is, we tell ourselves that from the outset of a project that this time is going to be different than the last time. Whereas, the last time, our commit messages started off well but, by the end, we’re writing things like:
Fixed some things
Refactored the function
Sure, this is a bit facetious, but the point is that if you look at commit messages for a lot of projects, they start off far more detailed in the beginning than by the end of the project.
I’m guilty of this, too. How, then, do we stick with good commit messages (and specifically, good Git commit messages, since so many open source developers use that service)?
When it comes to version control with Git, it’s no secret that I’m a fan of Tower. In the WordPress development community, it’s not at all uncommon to hear others talk about why they love or hate GitHub, GitLab, Bitbucket, Subversion, or whatever source control system they are opting to use.
That said, I think it’s fair to say that learning Git has its advantages. Although WordPress uses Subversion for core, themes, and plugins, many developers (myself included) opt to use GitHub for some our projects. This doesn’t mean that learning Subversion should be optional, but I think learning how to use both is important.
For this post, though, I’m talking specifically about Git. Case in point: If you’re looking to contribute to some of the most popular plugins (such as Easy Digital Downloads) then you’ve nothing to lose with this.
There’s a portion of the WordPress development community who want to be able to manage their source code outside of Subversion but still send their code from GitHub to WordPress.org.
Granted, some great strides have been made in this area. Just this week, WP Tavern reported that we can now submit pull requests from GitHub to WordPress Core.
But what if you’re a theme developer or a plugin developer (or both), and you’re looking for a way to manage your code on GitHub but still take advantage of the resources offered in the WordPress.org repositories?
You’re stuck between choosing Subversion, choosing GitHub, managing two repositories, or figuring out a way to sync them. And in the latter case, that’s exactly what the following script does.
When it comes to talking about Git and WordPress, Subversion and WordPress, or any version control and WordPress, some people are immediately turned off.
Version control is scary. It’s overwhelming. It uses terms that aren’t clear as to what they mean; the advantages aren’t immediately evident, and the learning curve can be steep no matter how nice our GUIs get.
But in my opinion, if you opt to increase your ability as a professional developer working in the WordPress economy, learning a version control system is something that’s highly recommended.
The benefits far outweigh the learning curve, and once you get used to the workflow, you’ll likely wonder how you ever lived without it.
But the biggest challenge? Figuring out exactly where to start.
In the admittedly short time I’ve worked in software development, I’ve rarely seen a site like GitHub have such a level of success especially for something as nerdy as version control.
Don’t get me wrong: Version Control is a must have for any serious software development shops – be it a single person or a team of people. But the fact the site works so well, has a variety of quality clients, and doesn’t look like, y’know, developers built the site is such a huge plus.
And as much as I love open source and what GitHub has brought us, I often see development shops asking users to report issues on GitHub whenever they see them.
That’s never sat well with me.
The thing is, even though GitHub looks good, even though it works well, and even though it does its job well at doing what it’s meant to do, it’s still targeting an audience that’s very rarely going to be our core audience.