How We Use GitHub to Release Quality Code at RubyGarage

We take code quality seriously for two reasons: 1) we care about the products we develop, and 2) we don't want to waste our client’s time and money on unnecessary software maintenance and modifications.

We use a variety of techniques and tools to control code quality. One of these tools is GitHub. We regularly use GitHub for deploying our software. Its simple yet effective branching strategy helps us manage, support, and track all the code we write at RubyGarage. In this article we’ll describe the full cycle of work with GitHub from the start of a project to its production release.

1.?reate a New Project

As with other version control systems, in Git projects are kept in repositories. The first thing you need to do to create a new repository is give it a name. The name of your repository should be short and memorable so everybody involved in the project can easily find it. We named our repository "rubygarage-gitflow."

Next, we have to push our project to GitHub and create a Master branch. We need to run the following commands to create a git file for our application:

git init git add git commit -m "first commit"git remote add origin git@github.com:kirillweb/rubygarage-gitflow.gitgit push -u origin master

Now we have to enter the directory where the folder with our project will be stored and initialize the project. If this project already exists on GitHub, we can run the command

git clone git@github.com:kirillweb/rubygarage-gitflow.git

to copy it to our local system. If the project doesn’t exist yet, then an empty folder with the name "rubygarage-gitflow" will be created at the directory we specified.

2. Create a Development Branch

To create a development branch we have to run the command

git checkout -b development

where -b creates a new development branch.

If the development branch already exists locally, we can just use the

git checkout development

command. To see the list of all local branches on our computer we can run

git branch

And if we need to delete a local branch from our computer, we can easily do it with

git branch -D

2.1 Create a Feature Branch

Now that we’ve created the development branch, we’ll create a feature branch and name it (feature/). To create this branch we have to run the command

git checkout -b feature/blog

This feature branch splits off from the development branch. We can split off several feature branches at the same time.

For example: If we run

git checkout -b feature/blog

from the feature/ branch our feature branch will be split off from the feature/ branch, not from the development or master branch. We can do this in case our current feature branch isn’t merged to the development (it’s on the stage of code review). But we need this feature to develop the next one.

Branch names contain two components to clearly show what’s in the branch – feature/ for new functionality, bugfix/ for bug fixes, hotfix/ for hotfixes, and so on.

2.2. Commit Changes

Once we’ve made changes to a branch, we need to commit those changes to save them to our repository. Committing changes adds them to the branch. To commit changes we run

git add

or

git add --all

Then we type

git commit -m ‘delete some files, fix some bugs’

We could also use

git commit --amend

This command will save all changes to the existing commit, but that’s not a very good practice and we avoid doing this in most situations.

2.3 Push the Project

Pushing the project means sending changes to the remote GitHub server. All changes on our local computer are synchronized with the remote server to let other developers see the changes in the branch. To push the project to GitHub we use the command

git push origin feature/blog

But if we’ve committed changes with --amend we need to push the project with force by running the command

git push -f origin feature/blog

To push with force is dangerous because if other developers have made any changes to the branch that don’t exist on your local server (but are saved to the remote GitHub server), pushing with force will completely overwrite the server branch with your local branch (where only your changes are saved). In other words, you risk erasing newly written code.

After we’ve pushed our project to the remote GitHub server, the next step is to add all committed changes to the development branch.

2.4 Create a Pull Request

A pull request is like a message to the owner of the repository. You create a pull request when you notice problems or just want to make some adjustments to the already written code. One pull request should correspond to one bug or one feature. Don’t overload your pull requests.

2.5. Code Review

As soon as we’ve added a pull request, we have to get it approved by the whole team who’s working on the project. They have to review the committed changes and leave comments about anything that needs to be fixed.

Once changes are approved by the team, we can merge them into the development branch. It often happens that the development branch includes code not present in our local repository. This can cause conflicts between the branches. To resolve these conflicts we have to move the newest changes from the remote development branch to our local branch by running the command

git pull origin development

This command will completely update our local development branch.

Now we need to merge our new development with our feature branch – for example, feature/something-cool. This is called rebasing. To do a rebase we enter our branch

git checkout feature/something-cool

and then run the command

git rebase development

If there aren’t any conflicts we’re good to go, but if there are conflicts then the process of rebasing will stop and show us in which file a conflict occurred. For example, we might see that a conflict was found in the file.../app/models/order.rb. This is a hash of the conflict commit:

cb1abc6bd98cfc84317f8aa95a7662815417802d

After we’ve manually resolved the problem, we can continue rebasing by entering

git add git rebase --continue

We’ll continue this process until all issues are resolved and the rebasing is complete. After rebasing, we can run the command

git commit -m ‘rebase’ git push origin something-cool

and voila – we can merge!

During code review, everybody who takes part is assigned to a pull request. We can tag pull requests with labels such as "work in progress" (if, after code review, a developer will be making fixes). The process of code review looks like this:

After code review we merge this feature branch with the development branch.

3. Merge to Master Branch4. Merge to Production Branch

Our branching GitHub Flow is designed in the following way:

If you don’t want to use GitHub for some reason, there are alternatives such as GitLab and BitBucket. The general principles we just described apply to all popular version control systems. Working with a version control system such as GitHub helps to maintain high quality code.

Originally published at https://rubygarage.org/blog/release-quality-code-with-github

Sviatoslav Andrushko is a content manager at RubyGarage. Sviat adores writing about web development, web design, testing, and other IT-related topics.