Improve your pull request workflow using pull-request-codecommit

23 Feb, 2022
Xebia Background Header Wave

In my previous blog post, I wrote why it is important to write good commit messages.
In this post I will highlight an example how this works in your advantage. Using an AWS CodeCommit repository.

Working example

Alright, lets assume we have a project that uses a main branch. In combination with feature branches.
We want to add a feature to our project, so we create a branch called: feat/my-feature.

Let say we manage to get the feature working in a single commit. The commit message would look something like this:

feat: add support for x

By adding support for x we allow x users to adopt this tool in their workflow.

Issue: #123

Now it is time to create a pull request! I have created a tool called pull-request-codecommit.
This tool looks at the differences between the current branch. And the target branch and proposes a pull request message.

So if you want to create a pull request you type:

git pr

The default editor is opened. And in this editor you will see:

feat: add support for x (#123)

By adding support for x we allow x users to adopt this tool in their workflow.

Issue: #123

The first line will be used as the title and the rest as a description.
You can alter the message to your liking, but if you use a proper commit message this is spot on already.
When you save the proposal the pull request is created for you:

For convienience the link is displayed and the eventual message. When you open the link the pull request will look like this:

What about many commits?

When many commits are used the tool tries to propose a good pull request message. When you split your commits.
And you used proper messages it looks something like this:

As you can see, the first commit is used as the title. The rest of the commit titles are shown as a list in the description.


When you write proper commit messages, you help your self. It makes it easier for you to draft pull requests.
And it allows you to start using tools because you use standards.

Joris Conijn
Joris has been working with the AWS cloud since 2009 and focussing on building event driven architectures. While working with the cloud from (almost) the start he has seen most of the services being launched. Joris strongly believes in automation and infrastructure as code and is open to learn new things and experiment with them, because that is the way to learn and grow. In his spare time he enjoys running and runs a small micro brewery from his home.

Get in touch with us to learn more about the subject and related solutions

Explore related posts