If you’re someone who regularly develops software, sites, or anything with any code, you’re going to start using source code control at some point.
And when a project ends, you’ve got options when it comes to maintaining the source code:
- Perhaps you’ll hand the code over to the client, and you will retire it,
- Or maybe you’ll continue to maintain it for the client as part of an ongoing relationship,
- Or there’s a chance you’ll be done with the project but still want to hang on to the source code.
For me, I’m partial to the latter option primarily because I like to have an archive of the things I’ve worked on throughout my career (no matter how trivial they may be) and because I’m a bit of a packrat when it comes to things like this.
Because if a client ever comes back for future work on a project, then I want to be able to spin up a copy of the development environment so I can get back to work. This assumes that I have an archive of the source, though.
But this assumes I have a repository archive.
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
- Removed stuff
- 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.
So what’s a good resource for doing just that?
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.