This document outlines a Git branching model to allow for smooth development with isolated features. The model uses main branches of master and develop, and support branches of feature, release, and hotfix. Feature branches isolate new work and merge back to develop. Release branches prepare releases and merge to both develop and master. Hotfix branches address urgent bugs in master and also merge to both develop and master. This model aims to allow multiple developers to work independently while reducing conflicts and enabling flexible releases and rollbacks.
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
Two days git training with labs
First day covers git basis and essential commands
Second day covers git additional command with a big lab using a git workflow
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/
Do you know the basics of Git but wonder what all the hype is about? Do you want the ultimate control over your Git history? This tutorial will walk you through the basics of committing changes before diving into the more advanced and "dangerous" Git commands.
Git is an open source, distributed version control system used to track many different projects. You can use it to manage anything from a personal notes directory to a multi-programmer project.
This tutorial provides a short walk through of basic git commands and the Git philosophy to project management. Then we’ll dive into an exploration of the more advanced and “dangerous” Git commands. Watch as we rewrite our repository history, track bugs down to a specific commit, and untangle commits into an LKML-worthy patchset.
Introduction to Git & GitHub.
Agenda:
- What’s a Version Control System?
- What the heck is Git?
- Some Git commands
- What’s about GitHub?
- Git in Action!
Best practices with git - The essentials you should know about git to use if efficiently
Workshop by Otto Kekäläinen at OpenFest 7.11.2015, Sofia, Bulagaria.
This 68 slides beast surely has something new even for seasoned git developers!
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
Two days git training with labs
First day covers git basis and essential commands
Second day covers git additional command with a big lab using a git workflow
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/
Do you know the basics of Git but wonder what all the hype is about? Do you want the ultimate control over your Git history? This tutorial will walk you through the basics of committing changes before diving into the more advanced and "dangerous" Git commands.
Git is an open source, distributed version control system used to track many different projects. You can use it to manage anything from a personal notes directory to a multi-programmer project.
This tutorial provides a short walk through of basic git commands and the Git philosophy to project management. Then we’ll dive into an exploration of the more advanced and “dangerous” Git commands. Watch as we rewrite our repository history, track bugs down to a specific commit, and untangle commits into an LKML-worthy patchset.
Introduction to Git & GitHub.
Agenda:
- What’s a Version Control System?
- What the heck is Git?
- Some Git commands
- What’s about GitHub?
- Git in Action!
Best practices with git - The essentials you should know about git to use if efficiently
Workshop by Otto Kekäläinen at OpenFest 7.11.2015, Sofia, Bulagaria.
This 68 slides beast surely has something new even for seasoned git developers!
Moving to Git opens up a whole new level of agility for software teams. Freed from the clunky code freezes and monolithic mega-merges that plague centralized version control, developers can isolate work in progress and build in narrow vertical slices with ease. Branching is so painless with Git that many teams are making new branches for each user story or bug fix they implement. This model is quickly becoming the new gold standard for agile teams – and for good reason!
Reconstructing the past with media wikiShawn Jones
The Internet Archive attempts to reconstruct web pages via snapshots (Mementos) that are taken of pages at various points in time. Many pages change more frequently than the Internet Archive can capture them, meaning that some revisions of a given web page are lost forever. Mediawiki, however, has all past revisions of a given page, and also its associated external resources. This inspired the development of the Memento Mediawiki Extension as an improvement over the Internet Archive's "drive by" method of digital preservation where Mediawiki sites are involved.
While working on the Memento Mediawiki Extension, effort was put into reconstructing past revisions of each Wiki page. The existing software reconstructs the page text as per RFC 7089, but does not try to pull in past versions of images, JavaScript, CSS, and other external resources, because Mediawiki, as it exists, makes it difficult or impossible to load these resources at page generation time.
This curated talk will explore the problems of page reconstruction on the main web and detail the issues within the Mediawiki code that currently prevent and/or make it difficult to reconstruct the page in its totality as it looked at that revision.
Speaker: Jesse Anderson (Cloudera)
As optional pre-conference prep for attendees who are new to HBase, this talk will offer a brief Cliff's Notes-level talk covering architecture, API, and schema design. The architecture section will cover the daemons and their functions, the API section will cover HBase's GET, PUT, and SCAN classes; and the schema design section will cover how HBase differs from an RDBMS and the amount of effort to place on schema and row-key design.
Jenkins and Chef: Infrastructure CI and Automated DeploymentDan Stine
This presentation discusses two key components of our deployment pipeline: Continuous integration of Chef code and automated deployment of Java applications. CI jobs for Chef code run static analysis and then provision, configure and test EC2 instances. Release jobs publish new cookbook versions to the Chef server. Deployment jobs identify target EC2 and VMware nodes and orchestrate Chef client runs. The flexibility of Jenkins is essential to our overall delivery architecture.
HBaseCon 2012 | HBase Filtering - Lars George, ClouderaCloudera, Inc.
This talk will run through the list of filters that are shipped with HBase and show how they are used from a client application. Filters expose varying feature sets, but also exhibit an equally varying impact on read performance – but neither are directly intuitive. A skilled HBase practitioner should know how to select the proper filter for a given use-case, or how to combine sets of filters to achieve what is needed. The talk will conclude with an example for a custom filter and explain how to deploy it on a cluster.
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.
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.
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.
Wern Jien present recommended workflow for using Git. He even demonstrate it using animation on https://veerasundar.com/blog/2018/03/gitflow-animated/. This is presented at Inno Tech Bootcamp 2 on 5th July 2018. #ITBC2
Git and Git Workflow Models as Catalysts of Software DevelopmentLemi Orhan Ergin
This is the slides of my latest talk in DevFest Istanbul 2013 which is organized by Google Developers Group Istanbul. The content mainly has 3 sections. Git branching model in theory, creating a feature by git commands and git best practices.
1. A successful Git branching
model
For a smooth and non conflicting development experience
2. The Problem
- Multiple member working on different parts unnecessarily delaying each
other.
- Cant release urgent changes because there are uncomplete features in the
code .
- Inability to isolate features for testing.
- Inability to revert a specific feature without reverting other features or code
changes.
- A lot of time wasted on merge conflicts.
3. The Goal
- Focus on a specific target while developing.
- Be able to apply urgent changes
- Isolate features for testing.
- Flexibility and ability to revert features or code parts without affecting other
parts.
- Ability to work on features for distant releases.
- Reduce merge conflict time.
4. The model
Main Branches
- Master Branch
- Develop Branch
Support Branches
- Feature branches
- Release branches
- Hotfix branches
5. Main Branches
- These Branches will always be there and live as
long as the project lives
- Master should always reflect a production-ready
state.
- Develop reflects a state with the latest delivered
development changes for the next release
6. Support Branches - Feature
Feature branch is used to develop a new feature for the next or a distant
release.
May branch off from : develop
Must merge back into : develop
Branch naming convention:
anything except :
master,develop, release-*, or hotfix-*
7. Support Branches - Feature
Create a feature branch from the develop branch
Implement the feature .
When done , merge back into develop branch
$ git checkout -b myfeature develop
// do the coding
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
8. Support Branches - Release
- Should be created once ready or almost done for a new release.
- no new features should be added here
- Clears space for other team members to work on new features from the
development branch.
- Changes on this branch should be done to solve bugs found before release
- Metadata , version number ,build data , etc...
May branch off from : develop
Must merge back into : develop and master
Branch naming convention : release-*
9. Support Branches - Release
- Create a release branch from the develop
branch.
- Update release metadata.
- Solve any found bugs.
- When done , merge into develop branch and
release branch
- Give a tag on the master branch
- Delete the branch
$ git checkout -b release-1.2 develop
// do the coding
$ git commit -a -m "updated version
number”
$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2
$ git checkout develop
$ git merge --no-ff release-1.2
$ git branch -d release-1.2
10. Support Branches - Hotfix
- Hotfix branches are created when it’s
needed to apply urgent changes or
hotfixes for bugs detected on the
production that can’t wait for the next
release.
- Its behaviour is very similar to a release
branch because it eventually creates a
new release.
May branch off from : master
Must merge back into : develop and master
Branch naming convention : hotfix-*
11. Support Branches - Hotfix
- Create a hotfix branch from the develop branch.
- Update version.
- Solve any found bugs.
- When done , merge into develop branch and
release branch
- Give a tag on the master branch
- Delete the branch
$ git checkout -b hotfix-1.2.1 master
// apply hotfix and update version number and
metadata etc..
$ git commit -m "Fixed severe production
problem"
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
$ git branch -d hotfix-1.2.1
