Everyone has a different git workflow set up but for the purposes of this post, assume that you’ve got something like the following:
- A branch in which all of your assets, unbuilt, reside.
- A system of continuous integration that builds the assets and creates a new branch or perhaps a new version.
- A branch that’s created by the continuous integration system that contains the built assets.
The main component of this workflow is the continuous integration system. That is, if it fails, then the work responsible for building the assets and creating a new branch no longer work.
And when that happens, we’re left having to do it manually. It’s tedious, sure, but not difficult. If you find yourself in this position, here’s how you can go about building assets, merging git branches, and creating a versioned release.
When it comes to Bitbucket and GitHub, each offers their advantages and disadvantages. I’ve used them both and like them each for different reasons.
But I prefer GitHub for a few more reasons than Bitbucket (the least of which is not that my organization was hosted there). And I like to have everything, more or less, under the same service.
I’ve spent some time over the past week migrating from Bitbucket to GitHub. I currently maintain two personal accounts:
- one for myself,
- one for Pressware.
I’ve opted to downgrade my organization account to a personal account to save money and because I’m more or a less a company of one who occasionally has collaborators.
Various guides online leave something to be desired when it comes to walking through how to go about migrating from Bitbucket to Github, so I thought I’d share my experience for doing that.
When it comes to upgrading a an operating system, specifically if you’re on a Mac of any sort, people have mixed feelings. I’ve heard some people say they’ve lost a day’s worth of productivity. I’ve heard others say that the upgrade worked flawlessly.
With two very minor hiccups, the upgrade to Mojave has been in the latter camp. Specifically, at the time of this writing, Firefox doesn’t mainly play well with writing to the filesystem via its standard dialog. And my installed of Git was hosed.
Depending on your history with working source control, the way in which you go about working with a codebase, making commits, etc., varies.
Further, depending on if you’re using Git, Subversion, Mercurial, and so on also dictate how you manage your code.
But if you’re someone who’s working with Git (which I know many people in WordPress are starting to use more and more almost on a daily basis), there are some small things that I recommend doing to help make managing changes espcially with a team more manageable.
Though most of us know we should never commit any sensitive information to a source code repository (be it Git, Subversion, or whatever), there are times in which it happens.
Most of the time, I imagine it happens whenever we’re working on code and then hopping back and forth between the IDE and a terminal and committing code to make sure we’re not losing any changes.
This happens long enough, and then we end up committing a consumer key and consumer secret or a username and password or something similar to the repository.
Luckily, we can remove commits to revert our code, but most source control systems end up keeping a history of everything (which is a good thing). But what if we need to go about removing Git commit history in both our local and remote repositories?