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?
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.