Quick Tip: Reinstalling Git on macOS Mojave

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.

Reinstalling Git on Mojave

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.

Read More

5 Ideas for an Enhanced GitHub Workflow

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.

Read More

Removing Git Commit History (Both Local and Remote)

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?

Read More

How (And Why) to Create a Repository Archive

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.

Read More

Writing Good Git Commit Messages

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

Read More