Git Workflow Using GitHub Action (Part 1)

Git Workflow

This workflow follows a trunk-based development paradigm. This is where small, frequent updates are merged to a core “trunk” or master branch.

Aside from the master branch, we will also have a development branch and multiple feature branches.

These branch types will be used as follows:

Feature: These will provide an isolated environment for every change to the codebase e.g. adding a new feature.

Development: This is where all thoroughly reviewed and tested code from feature branches will be merged. This will contain pre-production code.

Master branch: This will always have production-ready/working code merged from development.

To merge changes from two branches, will use pull requests (PRs).

PRs should be thoroughly reviewed and tested before merging.

GitHub Actions

GitHub actions will be used to run some automated tests whenever a new PR is merged into development and master.

Later on, more automated tasks could be done using actions e.g. generating builds, deployment

Step By Step Example

Add remote repository

git remote add origin https://github.com/user/repo.git

In this case, the added repo is hosted on GitHub and (locally) named origin.

Add the updated file to the staging area

git add filename

To add all files to the staging area use git add .

If you want to add patches (i.e. specific sections of the file that have been changed) then run the command

git add -p filename

Commit the changes

git commit -m "commit message here..."

Use single quotes to add a multi-line commit message (although it is best to keep the messages brief).

Push the new commits upstream, to a remote source (in this case, a repo on Github).

git push origin branch-name

Running tests using GitHub actions

GitHub Actions is a CI/CD platform for automating processes like build, test, and deployment. A workflow is defined and specifies jobs that are run whenever certain events are triggered e.g. running all tests whenever a new pull request is merged. Once a workflow is defined, it can be found under the “Actions” tab of the repository on GitHub.

The example below defines a workflow that is using Go.

name: Go

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:

  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Set up Go
      uses: actions/setup-go@v3
      with:
        go-version: 1.18

    - name: Build
      run: go build -v ./...

    - name: Test
      run: go test -v ./...

The on section defines the events that will trigger the jobs defined in the workflow to run. In this case, the workflow is listening for two events, namely:

• new commits pushed to the master branch.
• a pull request on the master branch.

The jobs section defines the jobs that’ll run when any of the events above occur. The first few steps under build just specify the environment where the jobs are to be run. The final two steps will build the application and run all its defined tests. If any of the jobs fail (the build or any of the tests), the workflow run will have a failure status.