Introduction

This post is part of my mini-series about AWS Developer Tools Services

• Part 1: AWS CodeCommit
• Part 2: AWS CodeBuild
• Part 3: AWS CodeDeploy
• Part 4: AWS CodePipeline

AWS CodeCommit

I’m looking for GitHub alternatives and thought CodeCommit would be worth a shot.

Creating a Repository

Like any other Git provider, you start with creating a repository.

As a side-note, I always thought what was lacking in GitHub was a way of grouping repositories. You can use topics which are essentially labels

I was hoping there would be a way to create folders or another way to group related repositories together but the closest thing they provide is using tags:

Connecting to repositories

After creating the repository it shows all the information needed for different protocols (HTTPS / SSH) and platforms (MacOS / Windows / Linux). One thing to note is that because of the security risks, it doesn’t allow you to connect with root credentials so you have to be logged in as an IAM user with CodeCommit full access.

I’m writing this blog post on a Windows laptop and so followed this guide for generating public/private keys.

It’s similar to any other Git guide with the exception that you have to add your access key to your SSH config file (~/.ssh/config):

Host git-codecommit.*.amazonaws.com
  User APKAEIBAERJR2EXAMPLE
  IdentityFile ~/.ssh/codecommit_rsa

Then to test your connection, run:

ssh git-codecommit.us-east-2.amazonaws.com

After adding the host to known hosts list you should see this message:

You have successfully authenticated over SSH. You can use Git to interact with AWS CodeCommit. Interactive shells are not supported.Connection to git-codecommit.us-east-2.amazonaws.com closed by remote host.

Clone the repo

On the same, click on the Clone URL dropdown and choose the protocol you’d like to use (ideally SSH):

and try it in your shell (Powershell in my case). You should see your repository locally:

Troubleshooting

In my experience in Windows, everything worked find on command line but when I tried to use my Git client (Git Extensions) I started having connection issues. The fix for that was to add my AWS SSH Key Id in the URL:

git clone ssh://Your-SSH-Key-ID@git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo my-demo-repo

Resources

• Setup Steps for SSH Connections to AWS CodeCommit Repositories on Windows
• Troubleshooting SSH Connections to AWS CodeCommit
• AWS Developer Tools services

In this post I woud like to talk about GitHub Flow branching strategy:

Basic approach

• Main diagram of the workflow:

• It’s a branch-based workflow mostly targeting projects where deployments are made regularly. In other words, it’s more suitable for continuos deployment environments.
• There’s only one rule about branching: anything in the master branch is always deployable. Because of this, it’s extremely important that your new branch is created off of master when working on a feature or a fix.
• Branch names should be descriptive
• Once the changes are done, create a pull request.
• Discuss the pull request and apply changes where necessary
• Merge into master and deploy straight away

Resources

• Understanding the GitHub flow
• YouTube Video: The GitHub Flow - GitHub Universe 2016
• YouTube Video: Git & GitHub: GitHub Workflow (A very concise explanation in 1 minute and 13 seconds)

In this post I woud like to talk about a common Git branching strategy: Git Flow.

Basic approach

• Main diagram of the workflow:

• The central repo holds two main branches with an infinite lifetime:

  • master
  • develop
• origin/master is the main branch where the source code of HEAD always reflects a production-ready state
• origin/develop is the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release (also called as integration branch)
• When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number.
• There are also supporting branches with limited lifetime such as:
  • Feature branches
  • Release branches
  • Hotfix branches

Automation

Most tools have plugins to support Git Flow. In the example below I will use SourceTree which is available in Windows and Mac.

In this example I’m going to use a GitHub repository called gitflow-automation-test. I’ve already created it in GitHub and in my development environment.

Initialization and working with features

First thing to do with Git Flow in SourceTree is to initialize the repository.

It sounds confusing at first because the git repo itself is already initialized. What it actually does is explained here. It shows a dialog box to configure the plugin:

It also created the local develop branch.

At this point we have the three types of branches explained above to choose from to start. Let’s start with a new feature named “users”

I just added a blank file that represents the changes required for that feature and commmited my changes.

Now that the feature has been implemented, I want to finish the feature. Similar to start, I went to Repository -> Git Flow -> Hg Flow -> Finish Feature

As the options in the window suggests, this action merges the changes into develop and deletes the local branch. It doesn’t push to remote so we have to push it ourselves.

Releasing new version

Now let’s assume we’ve implemented all the features planned for this release and we want to deploy a new version of our application.

To achieve this we start a new release:

Once we are ready to ship this release, we end the release similarly:

We can choose to push to the origin directly too. If we switch to detail view in Sourcetree output we can see a nice summary of actions that took place:

Summary of actions:
- Release branch 'release/1.0' has been merged into 'master'
- The release was tagged '1.0'
- Release tag '1.0' has been back-merged into 'develop'
- Release branch 'release/1.0' has been locally deleted
- 'develop', 'master' and tags have been pushed to 'origin'
- You are now on branch 'develop' 

Working with hotfixes

As the development continues, let’s assume we implemented another feature named “orders”. Finished the feature and pushed to origin. Now we have a new feature in develop. Suddenly we noticed there’s a bug in the production and we need to deploy a hotfix. We cannot create a new release branch off of develop because the new “orders” feature would be deployed along with the bugfix. So we create out hotfix branch off of master which always points to production.

As we can see the code reverted back to master:

So I added another file to represent the changes for the hotfix and finished the hotfix:

And the summary of actions looks like this:

Summary of actions:
- Hotfix branch 'hotfix/1.0-hotfix-1' has been merged into 'master'
- The hotfix was tagged '1.0-hotfix-1'
- Hotfix tag '1.0-hotfix-1' has been back-merged into 'develop'
- Hotfix branch 'hotfix/1.0-hotfix-1' has been locally deleted
- 'develop', 'master' and tags have been pushed to 'origin'
- You are now on branch 'develop'

As we can see the process is very similar to release. The only difference is the originating branch which was master in this case.

Working with pull requests

It’s a good practice to create pull requests and ask colleagues to review the code before merging into develop. This can still be part of Git Flow.

In this example I’ve created a new feature called “customers”. The changes are represented by the file “Implemented Customers Feature in This File.md”. I’ve commited my code to my feature branch and pushed it to GitHub.

Now I can click a new Pull Request by clicking Compare & pull request button:

I’ve clicked on Create Pull Request and now it’s open on GitHub.

At this point there are several strategies you can take such as reviewed handling the merge and the developer deleting the local branch themselves (as there won’t be a Finish Feature step).

My suggestion is for the reviewer to Approve the pull request but not to merge it. Once the PR is approved, the developer receives a notification. Also the status of the PR can be seen on GitHub as well:

At this point the developer can go back to Git Flow and finish feature as shown previously.

Now that we know customers feature have been approved we can select that and finish that feature:

Summary of actions:
- The feature branch 'feature/customers' was merged into 'develop'
- Feature branch 'feature/customers' has been locally deleted; it has been remotely deleted from 'origin'
- You are now on branch 'develop'

At this point developer needs to push the merged develop branch to GitHub otherwise the recent change (approved customers change) doesn’t appear in remote even though the pull request was merged.

Even if you’re in the middle of another feature and have uncommited files you can still finish the approved feature so it doesn’t interrupt with your work.

Command Line

All the Git Flow commands explained above are also supported by command line but to be able to use them you have to install it:

brew install git-flow

Then you can start using it as

git flow <subcommand>

In Windows, command line tools come with the installer so no extra installation is necessary.

Resources

• Git Flow Original Blog Post: A successful Git branching model
• Full branching model PDF
• Coding Blocks Podcast: Comparing Git Workflows