Evgeny Goldin works as a Technical Evangelist for the JetBrains TeamCity CI build server. He speaks Java, JavaScript, Perl and Groovy. His favorite products are MediaWiki, Intellij IDEA, Git, Artifactory, Gradle, YouTrack and TeamCity. He enjoys driving, learning and solving challenging problems. He doesn't like wasting time and being unproductive and believes that simplicity, attention to details and tidy working environments are the most efficient approaches to successful delivery. Evgeny is a DZone MVB and is not an employee of DZone and has posted 17 posts at DZone. You can read more from them at their website. View Full User Profile

My Git Workflow

03.10.2011
| 10770 views |
  • submit to reddit

When you work with Subversion you don’t talk much about workflow because there’s only one available 99% of time:

..
svn update
svn status
svn commit
..

I have an "ss" alias to "svn update && svn status" combination which I run very frequently for any project I come across. I believe most Subversion issues are caused by not running those two simple commands in time.

But it is different in Git. Since network topology, branching methodology and behavioral patterns may vary for each team (and that’s what makes Git git!) there’s a place to talk about Git workflow.

In my projects I don’t use “feature branches” much but I always work with two branches: "master" and "dev". The development only happens in "dev" which is rebased and merged with "master" when I feel it makes sense. Nightly builds build them all but only "master" artifacts are deployed to Artifactory as snapshots.

For 2 projects I have 4 branches and three different environments where I could update any of them: home, office or netbook. As I felt there’s too much time spent on bringing each project in sync with GitHub, I put together a number of scripts to update and push changes for each of them easily.

"update.bat":

@echo off

call git checkout dev
call git status
call git pull origin dev
call git checkout master
call git status
call git pull origin master
call git checkout dev

"merge.bat":

@echo off

call git checkout dev
call git status
call git rebase master
call git checkout master
call git status
call git merge dev
call git push origin
call git checkout dev

So when I approach a project I just type "update" to get it started or "merge" to wrap it up. There’s also a "merge-all.bat" script to call it a day:

 

@echo off

cls
e:

echo "=========> gcommons"
cd \projects\gcommons
call update
call merge

echo "=========> maven-plugins"
cd \projects\maven-plugins
call update
call merge

echo "=========> scripts"
cd \projects\scripts
call git status
call git pull origin master
call git push origin master

echo "=========> maven-plugins-test"
cd \projects\maven-plugins-test
call git status
call git pull origin master
call git push origin master

If everything is clean and no updates are left behind, I expect it to display:

"=========> gcommons"
Already on 'dev'
# On branch dev
nothing to commit (working directory clean)
From github.com:evgeny-goldin/gcommons
* branch dev -> FETCH_HEAD
Already up-to-date.
Switched to branch 'master'
# On branch master
nothing to commit (working directory clean)
From github.com:evgeny-goldin/gcommons
* branch master -> FETCH_HEAD
Already up-to-date.
Switched to branch 'dev'
Already on 'dev'
# On branch dev
nothing to commit (working directory clean)
Current branch dev is up to date.
Switched to branch 'master'
# On branch master
nothing to commit (working directory clean)
Already up-to-date.
Everything up-to-date
Switched to branch 'dev'
"=========> maven-plugins"
Switched to branch 'dev'
# On branch dev
nothing to commit (working directory clean)
From github.com:evgeny-goldin/maven-plugins
* branch dev -> FETCH_HEAD
Already up-to-date.
Switched to branch 'master'
# On branch master
nothing to commit (working directory clean)
From github.com:evgeny-goldin/maven-plugins
* branch master -> FETCH_HEAD
Already up-to-date.
Switched to branch 'dev'
Already on 'dev'
# On branch dev
nothing to commit (working directory clean)
Current branch dev is up to date.
Switched to branch 'master'
# On branch master
nothing to commit (working directory clean)
Already up-to-date.
Everything up-to-date
Switched to branch 'dev'
"=========> scripts"
# On branch master
nothing to commit (working directory clean)
From github.com:evgeny-goldin/scripts
* branch master -> FETCH_HEAD
Already up-to-date.
Everything up-to-date
"=========> maven-plugins-test"
# On branch master
nothing to commit (working directory clean)
From github.com:evgeny-goldin/maven-plugins-test
* branch master -> FETCH_HEAD
Already up-to-date.
Everything up-to-date

 

From http://evgeny-goldin.com/blog/my-git-workflow/

Published at DZone with permission of Evgeny Goldin, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Vijay Aravamudhan replied on Thu, 2011/03/10 - 5:28am

For iterating through a slew of git repositories (projects), I created a bunch of scripts, which are publicly hosted at: https://github.com/vraravam/git_scripts

 These are currently used on mac osx and linux, but can be used in windows with cygwin. The key is the 'run_all' which is called by almost all the others. So, in your case, you can invoke it like: 'run_all merge', 'run_all update'- without hardcoding each specific project. I have used this for over the past 3 years on different clients where I had to track and manage more than 16 projects at a time.

HTH, Vijay

Evgeny Goldin replied on Thu, 2011/03/10 - 7:46am in response to: Vijay Aravamudhan

Thanks, Vijay! Will try them out.

Joe Neuhaus replied on Thu, 2011/03/10 - 11:52am

Evgeny,

I noticed in your 'update' script you explicitly pull down 'dev' and 'master' branches; however, in the 'merge' script you only push the 'master' branch (implicitly I think.)  How does the 'dev' branch ever get pushed to the origin repository so you're certain to retrieve the most recent development work when you switch from work to home to netbook environments?

BTW, nice post!

---Joe---

Evgeny Goldin replied on Fri, 2011/03/11 - 10:09pm in response to: Joe Neuhaus

Hi Joe, Good eyes you have and thanks!

"git push origin" pushes both branches. Here's documentation mentions ("Example", second example) it this way:

"git push origin": Without additional configuration, works like git push origin :. Push "matching" branches to origin. ... The special refspec : directs git to push "matching" branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side. This is the default operation mode if no explicit refspec is found.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.