marlou knowledge base

# Git - workflow

# differents sources for brainstorming

The main important one, which is "devops compatible" : Understanding the GitHub Flow

# others workflows

# Git workflow list

Git team workflows: merge or rebase? - www.atlassian.com/blog - 20131028

Rebase as cleanup:

  • You’re developing locally.
  • Your code is ready for review.
  • Review is done and ready to be integrated into the target branch.

Rebase team policy:

When a feature branch’s development is complete, rebase/squash all the work down to the minimum number of meaningful commits and avoid creating a merge commit

Pros:

  • Code history remains flat and readable.
  • Manipulating a single commit is easy (e.g. reverting them).

Cons:

  • Squashing can hide context
  • Rebasing doesn’t play well with pull requests
  • Rebasing can be dangerous!
  • It’s more work
  • you need to force push at some point

Merge team policy:

When a feature branch is complete merge it to your target branch (master or develop or next).

Pros:

  • Traceability

Cons:

  • History can become intensely polluted by lots of merge commits

# opensource contrib on GitHub

How to Contribute to an Open Source Project on GitHub

  • Introduction to GitHub 0:47
  • Exploring GitHub 1:47
  • Exploring a Repository 4:07
  • How to install Git SCM 2:15
  • How to authenticate with GitHub using SSH 3:34
  • Identifying How to Contribute to an Open Source Project on GitHub 2:15
  • How to Fork and Clone a GitHub Repository 2:41
  • Setting up the project locally 1:18
  • How to create a Pull Request on GitHub 6:19
  • How to Collaborate on a Pull Request on GitHub 2:21
  • How to update a Pull Request on GitHub 2:57
  • How to rebase a Git Pull Request branch 3:39
  • How to squash multiple Git commits 2:53
  • Getting a Pull Request Merged and Wrapping up 1:13

# merging strategy

Dilemne avec worklow Git et intégration continue - www.developpez.net/forums - 2016

In a CI strategy you can merge in master at the start of the day to prevent painful merges at a later time. In a synchronization point strategy you only merge in from well defined points in time, for example a tagged release.

# synchronization point strategy

Based on an email from Linus Torvalds about merging strategy for linux dev.

# TLDR

Goals : I want clean history, but that really means (a) clean and (b) history.

# clean
  • People can (and probably should) rebase their private trees (their own work). That's a cleanup.
  • But never other peoples code. That's a "destroy history".
# history
  • Keep your own history readable
  • Don't expose your crap.
  • Don't merge upstream (ie : pull) code at random points.
  • Don't merge downstream (ie : push) code at random points either.

# Continuous Integration strategy

Based on Martin Fowler quotes in GitLab documentation.

If your feature branches commonly take more than a day of work, look into ways to create smaller units of work and/or use feature toggles.

# pros

  • merge your work every day
  • pull others work every day
  • CI oriented
  • painless merge
  • easier for devs to handle
# cons
  • feature flipping is mandatory to be able to deliver a clean product
  • more difficult for dev to handle

← npm memo →