Versions Compared

Old Version 28

changes.mady.by.user Tim Gerversmann

Saved on

compared with

New Version 29

changes.mady.by.user Tim Gerversmann

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Preparations before Starting

Understanding the Git basics

Not sure what a pull request is, or how to submit one? Take a look at GitHub's excellent documentation at https://help.github.com/articles/about-pull-requests/ and https://help.github.com/en/articles/creating-a-pull-request first.

To create a pull request, please refer to GIT basic, which gives a detailed description of the commands needed.

Configure Git to use real name in commits

Please configure git to use your real first and last name and your git noreply email adress for any commits you intend to submit as pull requests, e.g.
Author: First Last <your_account@users.noreply.github.com>

...

Code Block
cd taskana
git config user.name "John Doe"
git config user.email john_does_github_account@users.noreply.github.com

Warning

Where to find my github noreply email

Go to Settings→Email in your account. Under "Keep my email addresses private" you can find the no reply email with your specific account. Also be sure to set this check box and the  check box "Block command line pushes that expose my mail" also to avoid check ins with email other than the noreply address.

Pull Request Pipeline

Info

Each change to the master branch is done by a pull request (PR). A PR has to be reviewed and approved by one or many reviewers before merging into production code. A submitter is a person who creates the pull request. A reviewer is a person who will approve or decline the pull request at its current state. A merger is a person who finally integrates the PR into the master branch.

Our definition of a good pull request

  • Single responsibility → split PR if possible

  • Preferring small PRs

  • No unneeded changes (like different formatting, makes hard to read the diff)

  • Comment on important reasons of “why this changes” on the PR (not the code itself)

  • Solve merge conflicts (may also happen after PR is created)

  • Leave code a little better than you checked it out

Before creating a pull request

  • Run all tests, verify checkstyle

  • Format your commit messages in the following way:

    • Prefix Git commit messages with the ticket number, e.g. "TSK-140: xyz"

    • Describe why you are making the change, e.g. "TSK-140: Added logback to suppress the debug messages during maven build" (not only "changed logging")

  • Review your diff & changes → be happy or rework your PR

  • Remove unneeded changes to make the review simpler

  • Don’t use a ticket again if the ticket is already part of a release

When creating a pull request

After approval

  • The submitter merges his PR, not the reviewer

  • If PR is changed after approval, approval is removed

After the merge

  • After successful integration of a pull request, verify bluemix test environment is not broken

  • The merger puts the ticket to “integrated”

Git Command Pipeline

The Git infrastructure is set up as follows:

...