The main important one, which is "devops compatible" : Understanding the GitHub Flow
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
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.
Based on an email from Linus Torvalds about merging strategy for linux dev.
Goals : I want clean history, but that really means (a) clean and (b) history.
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.