rb-git-workflow.org

Git Workflow in GitLab

Introduction

The workflow mostly follows GitLab Flow git branching and workflow.

Start a project

1. create repo on git.chenla.org

   this repos will be origin

2. on your box either:
   • clone repo from git.chenla.org
   • create empty repo, git init, git add ., =git commit -m “initial commit”= then add a remote that points to the new repo.

Create permanent branches

1. stage, production
2. create webhook stage builds and deploys to beta.example.com
3. create webhook production deploys to www.example.com

Add a feature

1. Make sure you are in master, this should be the default.
2. Create an issue in GitLab that describes what you will do.

   “create base web site using Bootstrap, Font Awesome and Jekyll”

   Assign your self to the issue.

3. create branch that begins with the issue number

   “#2-create-base-site”

4. checkout the new branch, do the work.
   • create merge request with no assignee to get feedback
   • when ready, assign the merge request to the person in charge of merging for final review.
   • after it’s been approved, merged, and the issue closed, delete branch.

Deploy to Staging Environment

When master is ready for release, push to stage which will trigger tests and build. For web sites, it will also deploy to a staging web site where it can undergo final QA testing.

Any bugs found should be fixed in master and then cherry picked and merged into stage. This ensures that all bug fixes are in the main trunk and won’t get lost or forgotten.

For simple web projects there is no nead for a staging environment, as testing can be done directly from master so features can be pushed directly to production.

Deploy to Production

When stage has been reviewed and approved, push to production which will trigger automatic deployment to the server.