This is a presentation give to the Vancouver Drupal users group about moving to GIT as a version control system for a small development team. The presentation details the workflow we settled on, and the git flow method for branch management. You can see a video of the presentation here - http://www.ustream.tv/recorded/13544036
I was inspired to use GIT much more reliably after reading about Git Flow. I got a little lost until I read "Why Aren't You Using Git Flow?". I decided to do a presentation for OrlandoPHP to try and share my enthusiasm with them.
Thank you to Vincent Driessen and Jeff Kreeftmeijer for being my inspiration.
This is a presentation give to the Vancouver Drupal users group about moving to GIT as a version control system for a small development team. The presentation details the workflow we settled on, and the git flow method for branch management. You can see a video of the presentation here - http://www.ustream.tv/recorded/13544036
I was inspired to use GIT much more reliably after reading about Git Flow. I got a little lost until I read "Why Aren't You Using Git Flow?". I decided to do a presentation for OrlandoPHP to try and share my enthusiasm with them.
Thank you to Vincent Driessen and Jeff Kreeftmeijer for being my inspiration.
Git Introduction for beginners. Based on the Atlassian git tutorial.
git init, add, commit, push, pull, remote.
introduction to version controls.
git is a software version control and team management tool.
Excerpt from slides used in undergraduate software engineering lectures.
Our favorite git tricks, git commands and utilities that make working with git easier.
Updated June 2015.
Web development, from git flow to github flowCaesar Chi
software development, website development, we move develope way from git flow to github flow.
what is github flow's advantage and who we change it, check it out.
Git is a distributed version-control system for tracking changes in source code during software development.
GitFlow is a branching model for Git which is very well suited to collaboration and scaling the development team.
Git Introduction for beginners. Based on the Atlassian git tutorial.
git init, add, commit, push, pull, remote.
introduction to version controls.
git is a software version control and team management tool.
Excerpt from slides used in undergraduate software engineering lectures.
Our favorite git tricks, git commands and utilities that make working with git easier.
Updated June 2015.
Web development, from git flow to github flowCaesar Chi
software development, website development, we move develope way from git flow to github flow.
what is github flow's advantage and who we change it, check it out.
Git is a distributed version-control system for tracking changes in source code during software development.
GitFlow is a branching model for Git which is very well suited to collaboration and scaling the development team.
A Git Workflow Model or Branching StrategyVivek Parihar
Git branching model or Workflow. A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner. Git workflows encourage users to leverage Git effectively and consistently. Git offers a lot of flexibility in how users manage changes. This ppt is based on The Git Flow. It was created by Vincent Driessen in 2010 and it is based in two main branches with infinite lifetime:
master — this branch contains production code. All development code is merged into master in sometime.
develop — this branch contains pre-production code. When the features are finished then they are merged into develop.
Note: slides produced from the blog post of https://nvie.com/posts/a-successful-git-branching-model/
Managing releases effectively through gitMohd Farid
Best practices with GIT
Following some standard processes in GIT branching saved numerous nights in figuring what went wrong while merging some branches.
Don't be a git - the essentials you should know about git to use it correctly
Presentation by Otto Kekäläinen held at Vincit Teatime on Nov 11th 2015
http://www.vincitteatime.fi/
Vincit Teatime 2015.2 - Otto Kekäläinen: Don't be a gitVincitOy
Otto Kekäläinen from Seravo Oy gave a talk on how to use git correctly.
Don't be a git or The essentials you should know about git to use it correctly
Git on Linus Torvaldsin kehittämä versionhallintatyökalu, jonka ominaisuudet riittävät maailman laajimman ohjelmistoprojektin tarpeisiin. Git itsessään on hyvä lähtökohta jatkuvan integraation, laadunvalvonnan ja tehokkaan monen kehittäjän ympäristön pohjatyökaluksi. Tehokas käyttö ja yhteistyö vaatii kumminkin työkalun hallinnan. Ovatko branching, merging, rebasing ja bisecting varmasti tuttuja käsitteitä? Kuule kokeneelta kehittäjältä parhaat vinkit ja ota git haltuun.
Gitflow - Branching and Merging Flow for GitMaulik Shah
As a consequence of its simplicity and repetitive nature, branching and merging are no longer something to be afraid of. Version control tools are supposed to assist in ranching/merging more than anything else.
Enough about the tools, let’s head onto the development model. The model that I’m going to present here is essentially no more than a set of procedures that every team member has to follow in order to come to a managed software development process.
In a community setting here at WeWork Labs in NYC, Kevin McNamee, our lead developer, presented an introductory course on adding git best practices to your team's dev workflow.
5. The Main Branches
The central repo holds two main
branches with an infinite lifetime:
1. master(always reflects a production-ready state)
2. develop( testable code, without any incomplete
features or code)
6. Supporting Branches
1. Supporting branches are used for:
a. parallel development between team members
b. ease tracking of features
c. prepare for production releases
d. assist in quickly fixing live production problems
2. These branches always have a limited lifetime
Type of branches:
1. Feature branches
2. Release branches
3. Hotfix branches
4. Issue Branches
5. Your choice
7. Feature Branches
Branch off from: develop
Must merge back into: develop
Branch naming convention: feature-*
1. used to develop new features for the upcoming or a
distant future release
2. exists as long as the feature is in development
3. can be merged back into develop ( to add new
features)
4. or discarded (in case of a disappointing experiment)
5. Feature branches can be local branches or pushed to
origin if more developers are working on same feature
8. Release Branches
Branch off from: develop
Must merge back into: develop and master
Branch naming convention: release-*
1. preparation of a new production release
2. allow for minor bug fixes
3. meta-data for a release (version number, build dates, etc.)
When?
develop branch (almost) reflects the desired state of the new
release.
9. Hotfix branches
May branch off from: master
Must merge back into: develop and master
Branch naming convention: hotfix-*
When?
a critical bug in a production version must
be resolved immediately
10. Issue Branches
Must Branch off from: develop
Must merge back into: develop
Branch naming convention: issue#:issueId
IMP: mention #issueId in commit message.
This will link issue and the commit on github
When?
Issues are logged against you on github
issue tracker.
11.
12. Branch Per Task Approach:
1. Nobody must ever work on develop or master branch.
2. Always create a new branch for every task/issue/feature
3. Write code.
4. Test
5. Merge it back
6. Next task/feature/issue
13. Starting a task/feature/issue
1. switch to develop branch ( : git checkout develop)
2. pull latest develop from origin ( : git pull origin develop )
3. create new branch ( : git branch branch-name )
4. Switch to newly created branch( : git checkout branch-name)
5. Continue working….
14. After completing task/feature/issue
1. commit your code( : git commit -a -m “commit message” )
2. pull develop into current branch to make sure your code works with
latest develop branch(if updated by someone)(imp)
3. test functionality again
4. switch to develop branch ( : git checkout develop)
5. merge the task branch into develop ( : git merge branch-name)
6. delete branch branch-name ( : git branch -d branch-name )
7. Push develop back to origin ( : git push origin develop )
8. Next task / feature / issue
15. Things to remember:
1. Never perform more than one task in same branch
2. Use stashing if you don’t want to commit your code but still want to
checkout other branch or use later
3. Strictly follow naming conventions for branches and commit
messages
4. Delete branches once merged completely
16. Pull Requests:( Github )
1. Allows to review the code and then merge( not a git feature )
2. Open source project are managed with this approach