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.

Tips for an Enhanced GitHub Workflow

1. Don’t Commit to Master

Master should be used specifically for production-ready and deploy-ready code. It’s not you’re working branch, it’s not your working branch.

Generally speaking, this is where all pull requests are merged.

2. Try to Always Create Branches

Whenever you have a collection of tasks, issues, or milestones, then create a branch and make sure what you’re working on is all related. For example, you don’t want to be doing database work and JavaScript work in your pull requests.

3. Batch Your Work

Even if you’re working solely on front-end work, then you may need to split that up into smaller branches. It makes for easier code reviews and better pull requests.

4. Generate Small PRs

This is very similar to the previous heading, but the idea of creating small PRs are far more productive than creating longer pull requests.

  1. This helps when you need to request a code review as it gives your teammate(s) an easier way to handle code reviews and offer feedback.
  2. It keeps the change log lean and helps to give a detailed report of what the specific batch of code does.

But what constitutes a good PR?

5. Give Good Details in Your PR

As far as I’m concerned, a good pull request will do a small set of things:

  • Detail, in just a sentence or two, what the person reviewing your changes should expect to happen.
  • Link the PR to the ticket, project management card (or whatever they call it in your system),
  • List shorter versions of the commit messages to make it easy as possible for your peer reviewer.

That said, there are likely more things you can do, but these are the things I’ve found most useful (and I’d be remised to say I didn’t learn some of these things from my team).

Are There More Things?

Always.

But these are a handful of things that I’ve found to be more and more useful especially when tracking changes, working with others, and dealing with pull requests (both from those with whom I work and those who contribute to open source projects).

Finally, none of these things are prescriptive. There is a learning curve (speaking from experience), but I do recommend trying out a few of these if for no other reason than to see if it doesn’t enhance your workflow.

Even if it’s just a little bit.