Skip to content

Git Workflow🔗

Commit🔗

  • Commit early, commit often
  • A commit represents an idea or a change
  • Use verbs for your commits: add/remove/update/refactor/fix/config/hotfix
  • Do not commit console.log statements

Branches and workflow🔗

  • The development of new features and bug fixing usually takes place on features branches based on the dev branch. We use the Gitflow Workflow.
  • The development branch is named dev.
  • Use verbs for commits: add/remove/update/refactor/fix/config/hotfix. Commit messages should be in English and speaking.

  • Branches are deleted after merging.

  • Feature branches are updated with the remote branch using git command rebase and not with the merge command.

Further reading: merge vs. rebase

Below is a guide for rebasing:

Rebase a checked out feature branch with remote dev🔗

git pull --rebase origin dev

Repeat following steps until rebasing is completed:🔗

1. After solving each conflict:🔗

  • To check the rebase state of the current rebase step: 
    git status

2. If "Working directory clean" (No further changes are available)🔗

git rebase --skip

3. If "modified" (changes still exist)🔗

  • --> Resolve conflicts in the individual files. 
    git add [Path to file whose conflict has been resolved]
git rebase --continue

4. If "deleted" (Files have been deleted). Check whether displayed files should be deleted🔗

  • File will be deleted: 
    git rm
git rebase --continue
    File won't be deleted: 
    git checkout [File path]
git rebase --continue

Pushing results after finished rebasing🔗

  • If the feature branch has already been pushed (force push): 
    git push -f oder git push --force
    If the feature branch still exists: 
    git push

Pushing🔗

  • The commits are written to the repository with thematically closed pushes; however, the aim is not to include entire features in one push, but to model activities. Pushing your local development state on a daily basis is recommended to prevent data loss.

Definition Of Done🔗

  • Before opening a pull request, the author checks whether these conditions are met:
    • The target branch has been rebased to the feature branch immediately before opening the pull request. Hence, there are no conflicts.
    • The code is fine:
      • There are no warnings or errors in the linter report.
      • The code honors the conventions.
    • The documentation has been extended:
    • Test suites with tests are available:
      • For new functions: A short description of a test case to add it to the test protocol is provided. (Should result from the ticket.)
      • Unit tests are written: Test documentation
    • A functional tests on a build portal was executed:
      • According to ticket description.
      • Cross-Browser (Chrome, IE 11, FF) - mobile behavior emulated in the browser.

Forks🔗

Pull Requests🔗