An introduction to Git and GitFlow
Download as PPTX, PDF1 like889 views
This document provides an introduction to Git and GitFlow workflows. It describes Git as a distributed version control system and compares it to SVN. Key Git concepts and commands are explained such as branches, commits, remote repositories, and tools like SourceTree. The document outlines simple and GitFlow workflows suitable for different team sizes and project types. Branch naming conventions are also defined.
Ad
More Related Content
What's hot (20)
Similar to An introduction to Git and GitFlow (20)
Ad
Recently uploaded (20)
Ad
An introduction to Git and GitFlow
- 1. An introduction to Git and GitFlow (& how we use Git at Marie Curie) Mark Everard / @ev2000 Technical Lead
- 2. What is Git? • Git is a revision control system • Originally developed by Linus Torvalds (Linux Emperor!) • It is a distributed version control system • Very very widely used 42.9% May 2014, 36.3% May 2013 Full stats from https://en.wikipedia.org/wiki/Git_(software)
- 3. Its like SVN right? It is and it isn’t • It serves the same purpose It does it in a very different way • Has a steeper learning curve than SVN • Different terminology • Have to unlearn some SVN ‘knowledge’
- 4. Key differences • You checkout / clone a complete source control repository • You have the entire history of the repository on your machine • Simplifies merging – everything in Git is a branch https://git.wiki.kernel.org/index.php/GitSvnComparsion
- 5. Common git terminology ORIGIN Your centralised repository (for us this is GitHub – though in true DVCS there isn’t one) HEAD Where your current repository points.. Most of the time this is the latest revision in your branch
- 6. Common git commands Command line FTW Git command > git status Review what changes you’ve made > git add <files> Stages files for a commit (allows you to choose what to add) > git commit <files> Commit file to your HEAD source control
- 7. Common git commands Command line FTW Git command > git pull Pull down and merge commits from a remote repository > git push <remote> Push commits to a remote repository > git remote Lists all remotes that you have configured. You will generally have one (from GitHub)
- 8. Common git commands Sh*t I’ve made a mistake – how to undo Git command > git reset HEAD~2 (moves your head back two revisions) Undo changes that haven’t been shared with anyone else. Git will GC the dangling commits > git checkout HEAD~2 (moves your head back two revisions) Inspect what the state was 2 commits ago. Will detach head (meaning it doesn’t have a branch - BAD) > git revert HEAD~2 Reverting undoes a commit by creating a new commit (exactly what you’d do manually)
- 9. Tooling • One area where SVN is more advanced than Git • If you understand the basic commands GUI’s will make more sense • Pick one as a team, you can then support each other. My favourite is SourceTree
- 10. Principles • If it’s not in source control, it doesn’t exist • Commit early, commit often • Always inspect your changes before committing • Remember the axe-murderer when writing commit messages
- 11. Work flows • Git’s power actually comes from how you use it • SVN has a simple and rigid workflow (trunk, tags, branches) • Git offers many different type of workflows to suit different sized teams and release strategies
- 12. Simple Flow Good for small development teams and definite schedules Branch name Usage Rules master Represents the current code base that is deployed to production servers • Releases are taken from master • master should only be committed too directly in the case of a hotfix • Any direct commits should be up- merged to develop develop Represents the work-in- progress of all changes that are being made on the project • develop should be merged to master for a release • release should not be made directly from develop
- 13. Git Flow For complex multiple teams projects allowing flexible releases (feature branching)
- 14. Git Flow For complex multiple teams projects allowing flexible releases • Strict branching model • Feature branching
- 16. Branch name Usage Rules master Represents the current code base that is deployed to production servers • Releases are taken from master • master should only be committed too directly in the case of a hotfix • Any direct commits should be up-merged to develop develop Represents the current release candidate • develop should be merged to master for a release • release should not be made directly from develop feature branches Represent a single in- progress feature • Must branch from develop • Must merge to develop • Regular up-merging from develop should take place • Only merged to develop when QA is passed • Branches should be deleted when feature is merged release branches Represents a finalised release candidate • Must branch from develop • Must merge to master and develop • Bug fixes found during the UAT / Regression periods should be committed here • When the branch is ready to release, it should be merged to master and develop. • After the above merges / deployment the release branch should be deleted hotfix branches Represents a fix for an urgent issue found in production • Must branch from master • Must merge to master and develop • Branch should be deleted post merge • Never release from a hotfix branch
- 17. Branch naming The following conventions apply. General rules are to be descriptive and to allow the team to understand the feature. • release branches should be named release/{release-name} e.g. release/sprint-28 or release/picturewall-phase-1 • feature branches should be name feature/{name-JIRA-story/epic-number} e.g. feature/blog-bcweb-594 or feature/picturegallery-dam-4 • hotfix branches should be named hotfix/{JIRA-bug-number} e.g. hotfix/bcweb-3601 or hotfix/dam-90