Categories
Development Experiences Freelancing

Why I will be moving my private source code repositories away from GitHub

In case you’ve been living under a rock, it was announced on Monday that Microsoft as acquired GitHub for $7.5 billion. For various reasons, this has upset open source developers around the world.

Since then there has been a lot of discussion online about the pros and cons of this event. While I do feel that a lot of the complaints are probably coming from a vocal minority who are decidedly anti Microsoft (no doubt angrily typing their responses on Apple products, the irony) I also agree that this is perhaps not the best news for the open source movement in general.

Personally I will be moving my private (and possibly later public) git repositories over to GitLab and I thought it might be interesting to share my reasons why, if for no other reason than they were referred to as ‘a far sight more measured than most of the opinions about this that I’ve seen so far!‘. I feel like the world could use more measured opinions about popular or unpopular topics in general, so here goes:

  1. GitLab is open source, nuff said!
  2. While I don’t disagree that Microsoft has, under the leadership of it’s current CEO Staya Nadella, done a lot to prove that it now supports open source, something that the company was vehemently against in previous years, I feel it’s important to note that this change has only happened since Nadella took over as CEO 2014. This means that the company shift is directly as a result of the mindset of it’s CEO and that CEO will not be in place forever. The next leader of the company may not share Nadella’s love of open source.
  3. Personally, I don’t like the fact that any large company is in control of the world’s largest open source, code hosting platform. Did Microsoft really have to acquire GitHub to help it grow and improve? I would have been more impressed if Nadella had simply become a member of the GitHub board of directors and helped raise capital in order to support and grow GitHub, instead of outright buying it. Interestingly, this is a path that Matt Mullenweg took with GitLab about a year ago.
  4. GitLab has some cool features that GitHub doesn’t built right in, like Continuous Integration & Deployment on the free plan right up to Epics, Roadmaps and License Management on the top pricing tiers. They really seem to be building a seamless, integrated product for modern software developers and I want to support them in this cause.

I was already paying GitHub $7 a month to host my private repositories, so switching to GitLab’s $4 a month pricing plan will be a nice little saving each month. Not that I have to, as GitLab, like BitBucket, supports private repositories on the free tier.

And yes, I do know that if you were a GitLab user when a member of their staff managed to delete a database by accident you probably weren’t happy with them and moved on. I’m willing to give them a second chance.

 

Categories
Development Freelancing WordPress

What’s your Git Strategy?

As a freelance WordPress developer/consultant I rarely work in a team environment. So my usage of Git is mostly for my own purposes of being able to have my code backed up somewhere and the ability to create branches to try out new pieces of functionality without affecting the ‘master’ code base.

Recently I was chatting to Simon Dowdles, another Cape Town based WordPress developer, about this. He is, in his own words, very strict about a Git workflow. We agreed that it would be a good idea to implement a better system, so we put his workflow into place.

  1. Development branch is where all UP TO DATE and approved code lives
  2. Master branch is the truth and is ALWAYS what is on production
  3. Feature/hotfix branches are branched off of develop and only come back into develop with a Pull Request
  4. Release branches are made off of develop for releases, the release is done, merged back into master and tagged with the appropriate version tag (ie 1.2.0)
  5. Release branch is deleted, and there is only ever one

On the surface this all seems very obvious but it is often something that one tends to dismiss when working alone on the code base. After working with it for a few days however I can already see the benefits.

Lets first look at a real work example of how this would work in practice.

Setup

Firstly the repository is going to need a develop branch. So inside the root of my project folder I’ll create the develop branch from the master branch.

git checkout -b develop

And then push the branch

git push -u origin develop

If the develop branch already exists I can just switch to it

git checkout develop

Now I will need to create my feature branch, to make my code changes. So while still on the develop branch, create a a feature branch

git checkout -b feature/my-cool-feature

Usage

I can now starting coding my changes, committing frequently. I tend to commit every time I complete a chunk of functionality. So if I fix a bug, I commit. If I add a function and its more or less complete I commit.

git commit -a

At the end of every day, or if I am going to leave my workstation for a period of time, I push all current commits to the feature branch.

git push -u origin feature/my-cool-feature

When I am convinced it is good to go, I will submit a pull request or PR. When I create my PR I will request that it is merged into the develop branch, NOT master.

As we are using GitHub for this project I prefer to use the web based tools to create a PR, but most of the other cloud based Git services provide similar tools.

The rest of the team will review this PR, which will involve testing. They will scrutinise my code and provide feedback and I will fix or alter things to suit the team/project coding style(s).

Each time I commit the above changes, the team in the PR is notified and will see the changes in the PR.

When everyone is happy, they approve the PR and I merge my PR into the develop branch. At the same time I can choose to delete my feature branch (which I typically do)

The develop branch now has more (stable) code in it, and part of my PR should have been a version bump. (for example let’s say to 1.0.1)

Release

The team decides it is time to release version 1.0.1

First I need to make sure all my code is up to date

git pull

And then make sure I am in the develop branch. This is the branch that has all the approved code for the next release (1.0.1).

git checkout develop

I create a release branch called release/1.0.1 off of develop

git checkout -b release/1.0.1

The code gets deployed ( in this case its a WordPress plugin, so it means pushing all the code to the wordpress.org plugin repository, more on that another day 😉 )

 

I then merge the release/1.0.1 branch back into the master branch and tag it as release 1.0.1, again using all the GitHub PR, merging and tagging tools.

And we’re done, release 1.0.1 is in the wild and by following this approach, master is ALWAYS the truth. If for example release 1.0.2 were to fail, we simply roll everything back to master.

Wrap up

I’ve been working like this for three releases of the project so far and I have to say, once I had all the steps in my head, it did make developing, merging and releasing a lot smoother and more controlled.

Are you using Git as part of a team? If so I’d love to hear your comments on the idea of having a Git Workflow/Strategy.