Git branching strategies
•Descargar como PPTX, PDF•
3 recomendaciones•5,707 vistas
5 minute ignite about Git branching strategies
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Git branching strategies
Similar a Git branching strategies (20)
Más de jstack
Último
Último (20)
Git branching strategies
- 2. GIT Branching Strategies https://nl.linkedin.com/in/tizianatroukens @tizianatroukens Tiziana Troukens Web Application Consultant 20/09/2016 GIT Branching Strategies 2
- 3. GIT: Concepts 20/09/2016 GIT Branching Strategies 3
- 4. GIT: Concepts REF: pointer to an object TAG: special REF used to mark a commit in history 20/09/2016 GIT Branching Strategies 4
- 5. GIT: Concepts BRANCH: REF to a commit = HEAD 20/09/2016 GIT Branching Strategies 5
- 6. GIT: Branches 20/09/2016 GIT Branching Strategies 6
- 7. GIT: Branches 20/09/2016 GIT Branching Strategies 7
- 8. GIT: Merges 20/09/2016 GIT Branching Strategies 8
- 9. GIT: Concepts MERGE: keeps the context of the feature’s commits FAST-FORWARD MERGE: will shift the HEAD tag 20/09/2016 GIT Branching Strategies 9
- 10. Pull Requests • Commonly 2 reviewers • Share pull requests over the whole team • To avoid overloading a reviewer/developer • To spread knowledge of the codebase • To share your ideas • Provide a good, detailed description/ pull request name • Preferably provide a link to a build running in an environment -> TESTING 20/09/2016 GIT Branching Strategies 10
- 11. A Succesful Git Branching Model 20/09/2016 GIT Branching Strategies 11
- 12. A Succesful Git Branching Model 20/09/2016 GIT Branching Strategies 12
- 13. A Succesful Git Branching Model 20/09/2016 GIT Branching Strategies 13
- 14. A Succesful Git Branching Model: Naming conventions • Feature branches: “feature-*” (essentially: anything but “release-*”, “hotfix-*”, “master”, “develop”) • Release branches: “release-*” • Hotfix branches: “hotfix-*” • “/” are possible, so make team-specific conventions: • Username/workitem: “ttrouken/MT-7654” • Username/type: “ttrouken/bugfix” • Username/type/workitem: “ttrouken/feature/MT-7654”, “ttrouken/bugfix/ALM-85463” • Type/description: “hotfix/pageXdoesntload” • ... 20/09/2016 GIT Branching Strategies 14
- 15. GitHub Flow • Simple: every feature, every bugfix, every hotfix -> create a new branch • As soon as the feature, bugfix, hotfix is delivered -> merge back to master (pull request) • Before a merge to master happens: • Merge master back (rebase or merge, up to you) • Test thoroughly, make sure code is deployable! • Finally: create pull request to merge • As soon as merge happened, redeploy master • Preferably in a continuous way 20/09/2016 GIT Branching Strategies 15
- 16. GitHub Flow, but slightly different • Simple: every feature, every bugfix, every hotfix -> create a new branch • As soon as the feature, bugfix, hotfix is delivered -> merge to QA (pull request) • As soon as the QA branch is approved -> merge all approved features/bugfixes/hotfixes back to master (pull request) • Before a merge to master happens: • Merge master back (rebase or merge, up to you) • Test thoroughly, make sure code is deployable! • Finally: create pull request to merge • As soon as merge happened, redeploy master • Preferably in a continuous way 20/09/2016 GIT Branching Strategies 16
- 17. Branch Per Platform • One branch per platform, next to master • “staging” -> test environment • “QA” • “live” -> production environment • “integration” • ... • Master contains the latest development code -> could compare to “develop” in other models • As soon as code is deployed on an environment -> code is merged to the corresponding branch • Hotfix needed in production: • Fix code on “live” branch • Merge back to master • Fix will flow through to the other branches as development continues 20/09/2016 GIT Branching Strategies 17
- 18. Branch Per Release • One branch per release, next to master • “Release/1”, “Release/1/1”, ... • Release-branches are long-lived -> they can be “locked” but never removed • Master branch keeps a good, strong, stable codebase to start release branches from • When a release is good to go: • Create a FEATURE branch off master • Cherry-pick changes from RELEASE to this FEATURE • Merge FEATURE back to master • => release-specific changes stay in that release branch • Why not tagging? • Not automatically created (separate step from committing) • Not automatically pushed (need to use “push –tags”) 20/09/2016 GIT Branching Strategies 18
- 19. Case: Telenet Workflow • Master branch: currently on production • RELEASE_xx.xx branches: designated release • RELEASE_16.30, RELEASE_16.40, ... (quarterly) • Merged from master • FEATURE/BUGFIX branches • Merged from RELEASE_xx.xx • Pull requests back to RELEASE_xx.xx • No hotfixes • If really necessary, a PGL or emergency release can be opened • Actually: hotfix = “new release” 20/09/2016 GIT Branching Strategies 19
- 20. Case: Telenet Workflow • FEATURE/BUGFIX branches are never deployed • FEATURE done: • Pull request to RELEASE_xx.xx • RELEASE_xx.xx gets deployed on test environment -> auto-update minor version number (16.30.2) • Tag is created with full versioning (16.30.2) • Remove FEATURE branch • RELEASE done: • RELEASE gets deployed on production • Merge back to MASTER • No new tag is created! Done when releasing the RELEASE_xx.xx branch • Remove RELEASE branch 20/09/2016 GIT Branching Strategies 20
- 21. Common • Master = production code (almost always) - stable • Master and other “long running branches”: never commited to directly • Merge: use merge commits • Merge: pull request (code reviews) • Feature branches: regularly “git rebase” • Feature branches: merge & delete -> fully reviewed, fully tested! • Feature/Hotfix/Bugfix branch: single deliverable 20/09/2016 GIT Branching Strategies 21
Notas del editor
- A branching strategy is something you should decide on with the whole team. It defines your approach & attitude to the way you produce, track and ship code. -> the whole team should understand how the whole process works, how to collaborate, how to achieve your goal (= deliver the product) -> it is a structure of how you work -> GIT can be very flexible: search for a balance between flexibility & ease to collaborate & share code A branching strategy improves the quality of the work and the confidence & communication within the team. -> it’s sole purpose is to help you, help people. Not to help servers/networks/…, but to help them to help you. “To help you release software”. -> it’s sole purpose is to collaborate better & spend less time managing version control, but more time developing code!
- Branch: a POINTER to a commit! Representation in the .git directory is a simple text file containing the commit identifier of the current ‘tip’ (newest commit) on that branch. -> how is branch itself than ‘constructed’? By tracing the ancestry of that single commit -> every single commit always knowns its parent
- Merge commits are a bit different from normal commits: Each commit has a unique identifier (hex string), made from changeset, commit message, author, timestamp & parent commit The same commit applied to a different parent will have a different commit identifier – even if the resulting code is identical Merge commits have two parents: one from each of the branches being merged together
- Merging –> keep history of feature branches, in which release a merge was done –> easily ‘remove’ one full feature by simply reverting the merge commit –> easily ‘re-apply’ the same feature elsewhere, on another branch (by simply cherry-picking that one commit) –> easy to add code reviews / pull requests Fast-forward merging –> you have no pointer as to when/ in which release a merge happened –> rolling back a full feature = rolling back all commits one by one!
- 2 long-living (“eternal”) branches: master & develop - Should never be commited to directly, only via pull requests (code review) Master: production code Develop: code for the next big release
- New features -> merge feature-branch off from develop, merge back to develop only when fully done, reviewed and approved for the next release -> during development developers should ‘git rebase’ their changes onto develop regularly to avoid merge commits -> the release this feature will be in, may well be unknown at this stage!
- Almost ready for a new release -> merge release-branch off from develop, go to QA/Staging environment, make last bugfixes (NO NEW FEATURES), bump version -> when released, merge into master (= production code!), create tag on master and merge into develop -> bugfixes made can be merged back to develop even before going-live -> live: delete feature branch Hotfixes due in production -> merge hotfix-branch off from master, bump version & merge fix to master & develop/release-branch if existing (The essence of a hotfix is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix.) Remember: when something goes to master -> it goes to production -> CREATE A VERSIONING TAG