GIT
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model.
Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.
1. Basic Git commands
Following diagram, depicts the git model and the commands
- git init: Create a new local repository
- git status: List the files you've changed and those you still need to add or commit
- git clone: Create a working copy of a local repository
- git fetch <remote>: Fetch all commits from remote branch “upstream” into local repository
- git commit record your changes to the local repository.
- git push: Push the branch to your remote repository, so others can use it:
- git merge origin/<current branch>: To merge a different branch into your active branch
- git pull <remote>: Fetch the specified remote’s copy of the current branch and immediately merge it into the local copy. This is the same as git fetch <remote> followed by git merge origin/<current-branch>.
- tag: described in further section.
2. Branch
A branch is an additional line of development, where the developer can work independently of the main development line. When the developer is happy with the changes he made to the branch, he can push these changes into the main development line.
§ Branching enables parallel software development activities
§ Implement different features on braches for same code base
§ Maintain different releases in branches
§ Branching = ISOLATION
3. Basic Branches
For supporting the different development efforts and versions, the GIT Owner enforces the usage of the following branches:
- Master
- Development
- Feature Branch (1..n)
- Hot Fix (1..n)
4. Branching strategy
The
workflow is defined below:
- This workflow uses mainly 3
branches to track the history:
§ master branch,
§ development
branch
§ and feature
branch (1..n).
- The development branch is the default branch that tracks the
development activities and the master
branch keeps track of production code activities.
- The development (dev and QA) of
each feature will reside in its own feature branch. This isolates new development from finished
work and also allows development of multiple features at the same
time.
- Once the development of
feature is complete, after QA sign off, should be pushed to development
branch.
- Once we have enough features for
a release and are ready for testing, a release branch is created.
- After creating release
branch, no new features can be added to it. Only bug fixes,
documentation generation, and other release-oriented tasks should be
given in this branch.
- The code in the release branch is deployed
onto a suitable test environment, and tested, and if we find any
problems, they are fixed directly in the release branch. This deploy -> test -> fix ->
redeploy -> retest cycle continues until code is ready for
production release.
- Once it is ready to ship, the
code is deployed to production and the release
branch
gets merged into master
branch and tagged with a
version number.
- In addition, it should be merged
back into development branch
to reflect all the changes (bug fixed) that are made in release branch
§ For any
production issues a hotfix branch is
created. As soon as the fix is complete, the code is deployed to
production and it should be merged into both master branch
and development branch.
5.
Master Branch
§
Master branch must at all times, reflect what is
on the live production site.
§
When a new compiled version of an application is
validated and approved in production after its installation, the release branch is merged into this
branch
6.
Development Branch
§
Is the place where the development team merges
all the code.
§
Is the place where the merge issues between all
the parallel development efforts will happen.
§
Ideally, no direct development should happen on
this branch (just merge issues resolution)
§
The dev team can create as many Feature branches
out of this branch as required to support their development efforts.
7.
Feature Branch
§ Always create feature branch while working on
a new feature and feature branch should have a meaningful feature name for identification.
o Before starting the branch always perform git
pull and git status commands to get the latest code from
remote repository.
§ Commit the changes to the local repository.
o e.g. git add. (to add all
the files, for specific files use file name or folder name instead of
".")
o git
commit -m "ABC-1 #comment Initial commit for the
feature"
§ After the changes are staged, git
push command can be used to push commits made on your local branch to a
remote repository
o e.g. git push
<REMOTENAME> <BRANCHNAME>
§ Again when more than one person is working on
the same branch, whenever a change pushed by one can be consume by the other
using git pull command.
§ When the feature completed and review
completed it can be merged to the development
branch.
8.
Release branch
- After all
the desired features for a release is completed (as in merged in development
branch) a release branch has to created.
- The focus
for this branch is to harden the features within this release and make it
ready for the release. This can include testing and bug-fixes.
- Code
changes related to bug fixes should be done on this branch - git commands
are used during this process.
- The changes
have to be merged to development branch as well once done using git
commands.
- When the
code is ready for production deployment, merge(locally) changes to master
and in develop.
- Unlike
feature branch, when finishing the release branch, release notes should
be provided which is then tagged to master when release is merged with
master.
- To merge
the changes to development,
use git checkout development and git push commands as shown above.
- To merge
the changes to master use git checkout master and git
push --tags (to push the tags to remote along with the code)
9.
The Hot Fix Branch
- § This is a short duration branch created from master branch, and is created specifically for production bugs.
- The branch name has to be the bug id to provide tractability
- Its purpose is to create a patch (or hot fix) to solve a production issue
o Once the hot-fix is completed, release notes
has to provided and is merged to master
and development branch.
o For any hot fixes that gets into production
during development (feature /release hardening):
ü ensure that changes are pulled down
from development to feature branch (git
merge) before pushing the feature to develop.
ü ensure that changes are pulled down
from master to release branch (git
merge) before pushing the release to production.
10.
Tagging
Tagging is reference
used to capture a point in history that is used for a marked version release
(i.e. v1.0.1). A tag is like a branch that doesn’t change. Unlike branches,
tags, after being created, have no further history of commits.
Two types of Tagging:
§
Lightweight Tags
Another way to tag commits is with
a lightweight tag. This is basically the commit checksum stored in a file — no
other information is kept. This is for private, and generally version numbers
are stored.
git tag v1.4-lw
§
Annotated Tags
Use every time annotated tags rather
than Lightweight Tags. This would store tagger information, the date the
commit was tagged, tagger name, date and the annotation message before showing
the commit information.
git tag -a v1.4
-m "my version 1.4"
11.
Responsibilities
§ Dev Team:
o
Maintain all the Feature branches of the
Development Branch
o
Communication and coordination between the teams
working in all the Development Branch children branches
§ Hot Fix
Team:
o
Require creation of Hot Fix branches only when
needed: scheduled maintenance development should happen in a standard
development branch
§ GIT Owner:
o
Merges to and from Master Branch
o
Communicate to Dev team every time a change from
a Hot Fix branch is merged back into Production for rapid integration
o
Coordinate resolution of any merge conflict that
may arise
12.
Merge Conflicts
§
Always fix ALL Merge Conflicts.
§
Coordinate with the authors of the changes
§
Consult with the Scrum Master
§
Use a merge tool*
§
When in doubt, have a merge party
§
Communicate, communicate, COMMUNICATE!
13.
Best Practices
§
Use meaningful Branch name where applicable
§
Integrate early and often to avoid “Bing-bang
merge”
§
Avoid cascading branches
§
Preserve the physical integrity of the branch
§
Isolate Change
§
Isolate Work, Not People
No comments:
Post a Comment