top
April flash sale
Category
Courses

Search

GIT Tutorial

1. Branching Strategies :Why need a strategy? What is it?Need a set of rules/strategy to commit, merge and promote changes to a repository. This defines a git collaboration workflow.Let’s you define a structured delivery of work, increasing efficiency & reducing errorIntroduce opportunity for code review and protected branch.Exploring strategies to reduce merge conflictsClean your working directory before doing a mergeIf you have work in progress, either commit it to a temporary branch or stash itCommit often, and merge oftenCreate more of small topic branches rather than long running branchesPush/pull often, publish your work oftenRebase your work than merging only on your local repository and local branch.Separate different types of branches like: master, hotfixes, release, develop, feature & topic branches.Keep changes physically small. Small diffs, small amount of lines changed (easier to debug)Stable/Integration branch: (“prod”, “master_prod”)Stable long running branches with a clean history (--squash)Open branches and store historyRelease branch: (“release”, “pre-prod”)Stable long running branch with a messy history with all the feature and hotfix mergesFeature branch: (“dev”, “uat”)Very short-lived branches for specific issues or bugfixesThese are developed, merged into stable release branches and deletedUnstable/Hotfix branches: (“hotfix”, “quickfix”, “bugfix”, “QA”)These are not merged with all feature branches; hotfix branches may be private.After every branch (feature, hotfix, quickfix) branches are merged to the main branches, tag the latest commit for future reference and delete the branch.Follow the steps below:2. Structural Strategies- git repository structure strategiesSteps to develop the below git strategies or git branching strategy:NOTE: There is no fixed defined strategy; adapt the strategy based on your project and business needs.Clone the project:git clone http://github.com/divyabhushan/structuralStrategy.git structuralStrategyGuidelines: “master-prod”: Accepts merges/code/commits only from the “prod” branch“prod”: Perform only a merge --squash from “release” branch.Merge only when approved by “QA”Tag every merge in the format: v1.0, v1.1 … v1.*“release”: merge from the branches “dev”, “uat”, “QA”.Every release commit/project code version has to be approved by “QA”.Tag every merge in the format: r1.0, r1.1 … r1.*“dev” and “uat” never merge with each other.“hotfix” branch commits are shared among any feature branches such as “dev” and “uat”“feature” branch is private to “dev” alone and is dropped after merging.Diagram: Structural StrategyLab ExercisesA flexible exercise implementing the strategy you intend to use moving forwardcd structuralStrategy [Divya1@Divya:structuralStrategy [master_prod] $gitk --allTo continue developing your project:Latest release tag: r1.5, commit_id: 6785ec9 has to be merged into and approved (any edits if required) by QA.Once ‘QA’ approved, merge it back into ‘release’; tag with tag id r1.6.Merge this commit into ‘prod’ with --squash flag and tag it as tag: v1.3Merge this commit into ‘master_prod’
logo

GIT Tutorial

Collaboration Strategies

1. Branching Strategies :

Why need a strategy? What is it?

  • Need a set of rules/strategy to commit, merge and promote changes to a repository. This defines a git collaboration workflow.
  • Let’s you define a structured delivery of work, increasing efficiency & reducing error
  • Introduce opportunity for code review and protected branch.
  • Exploring strategies to reduce merge conflicts
  • Clean your working directory before doing a merge
  • If you have work in progress, either commit it to a temporary branch or stash it
  • Commit often, and merge often
  • Create more of small topic branches rather than long running branches
  • Push/pull often, publish your work often
  • Rebase your work than merging only on your local repository and local branch.
  • Separate different types of branches like: master, hotfixes, release, develop, feature & topic branches.
  • Keep changes physically small. Small diffs, small amount of lines changed (easier to debug)

Stable/Integration branch: (“prod”, “master_prod”)

  • Stable long running branches with a clean history (--squash)
  • Open branches and store history

Release branch: (“release”, “pre-prod”)

  • Stable long running branch with a messy history with all the feature and hotfix merges

Feature branch: (“dev”, “uat”)

  • Very short-lived branches for specific issues or bugfixes
  • These are developed, merged into stable release branches and deleted

Unstable/Hotfix branches: (“hotfix”, “quickfix”, “bugfix”, “QA”)

  • These are not merged with all feature branches; hotfix branches may be private.

After every branch (feature, hotfix, quickfix) branches are merged to the main branches, tag the latest commit for future reference and delete the branch.

Follow the steps below:

2. Structural Strategies- git repository structure strategies

Steps to develop the below git strategies or git branching strategy:

NOTE: There is no fixed defined strategy; adapt the strategy based on your project and business needs.

Clone the project:

git clone http://github.com/divyabhushan/structuralStrategy.git structuralStrategy

Guidelines: 

“master-prod”: Accepts merges/code/commits only from the “prod” branch

“prod”: Perform only a merge --squash from “release” branch.

Merge only when approved by “QA”

Tag every merge in the format: v1.0, v1.1 … v1.*

“release”: merge from the branches “dev”, “uat”, “QA”.

Every release commit/project code version has to be approved by “QA”.

Tag every merge in the format: r1.0, r1.1 … r1.*

“dev” and “uat” never merge with each other.

“hotfix” branch commits are shared among any feature branches such as “dev” and “uat”

“feature” branch is private to “dev” alone and is dropped after merging.

Structural Strategies- git repository structure strategies

Diagram: Structural Strategy

Lab Exercises

  1. A flexible exercise implementing the strategy you intend to use moving forward
cd structuralStrategy

[Divya1@Divya:structuralStrategy [master_prod] $gitk --all

Lab Exercises

To continue developing your project:

  1. Latest release tag: r1.5, commit_id: 6785ec9 has to be merged into and approved (any edits if required) by QA.
  2. Once ‘QA’ approved, merge it back into ‘release’; tag with tag id r1.6.
  3. Merge this commit into ‘prod’ with --squash flag and tag it as tag: v1.3
  4. Merge this commit into ‘master_prod’

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments

Ezeelogin

Thanks for the post. I liked the way all the details have been provided!

stephen

Firstly thanks for providing this tutorial from this article I have gathered lots of information. I can say that whatever the information provided by knowledgeHut is more useful to know more about the git.

Saurabh

Written nicely