Site-wide Tags:  Linux(17) | CommandLine(12) | Ubuntu(10) | RemoteAccess(7) | Tools(7) | Vim(7) | LiftWeb(5) | SBT(5) | SoftwareDev(5) | Mac(5) | Scripts(4) | WebDev(4) | Diagrams(4) | Lifty(3) | NetworkDrives(3) | Processwire(3) | Security(3) | Fog(3) | VCS(3) | BestPractices(3) | RaspberryPi(2) | WebDesign(2) | Encryption(2) | Windows(2) | SSH(2) | WinCommandPrompt(2) | GitHubRepos(2) | Emacs(2) | PHP(2) | IDE(2) | ErrorMsgs(2) | JVM(2) | Hardware(2) | Bash(2) | Networks(2) | Graphviz(2) | Cloning | Cygwin | Graphics | Java | SystemRecovery | lessc | Maven | Python | PXE | Samba | LXDE | PackageManagement | LifeHacks | LESS |

This site has been archived and will no longer be updated.
You can find my new profile at neilpahl.com. My new blog is at 808.ninja.

Entry 2: Snippets From A Great Git Branching Model

Topic: Version Control   

Tags:  SoftwareDev   VCS   

Created on Fri, 29 Jun 2012.
Last Modified on Sun, 08 Jul 2012.

A great git branching model was proposed on nvie.com and can be found here:

http://nvie.com/posts/a-successful-git-branching-model/

I highly recommend anyone to first go and read it since it is very elegantly explained, along with pleasant diagrams. Here, I'm just going to highlight a few of the code snippets for my own reference.

A] Main Branches

- There are 2 main branches... develop and master.
- Master is assumed to be production ready, develop is branched from master and merged back to master when it is stable enough.
- Master is tagged with a version each time it is updated.

Using my private repo that I set up in my last entry, I'll switch to the master branch(probably already starts there but I'll be explicit), then tag my first version of master

git checkout origin master
git tag -a '0.01' -m 'first version 0.01'

next, I would create and checkout a dev branch

git checkout -b develop master

which is just short for

git branch develop master
git checkout develop

so, if you don't need to checkout develop, you can jsut create it with 'git branch develop master'

push your local development branch to remote:

git push origin develop

B] New Features

-create and checkout a feature branch off of the develop branch

git checkout -b newFeature develop

-do work on the feature branch.. then update the feature branch

git add . 
git commit -m 'added blah to my feature'

- merge my feature branch with develop using no fast-forward, then delete the newFeature branch

git checkout develop
git merge --no-ff newFeature

-delete teh feature branch

git branch -d newFeature

-push back to develop

git push origin develop

C] Release Branch -> Production.

git checkout -b release-0.02 develop

- test the release branch. creating a new release branch is good practice so that the develop branch can still be worked on while testing is going on release. I'd imagine that on a smaller project one can just merge the develop branch into master
- merge release into production (master)

git checkout master
git merge --no-ff release-0.02
git tag -a 'version 0.02'

- merge back into develop

git checkout develop
git merge --no-ff master

-delete release branch

git branch -d release-0.02

D] Hotfixes

Just create a branch off of develop, release, or master, and merge it back after fixing the bug.

E] Some Other Usefull Git Commands

- view remote names with locations using

git remote -v

- view all local and remote branches with

git branch -a

- view remote branches with

git branch -r

+ add 'v' for some more info.. ie:

git branch -rv

- add remote branches:

git push <remote-name> <branch-name>

- delete remote branches:

git branch -d -r remote_name/branch_name

- reset your current project to match the repo (on origin master):

git reset --hard origin/master






PLEASE let me know if I'm doing something wrong, or if you have any suggestions or requests~

blog comments powered by Disqus

All Entries Within This Topic:

Subscribe to this topic:

Browse Topics: