House 9: February 2012

This is the current git workflow we are using at work, your mileage may vary:

	Always start with

	# get the latest code
	git checkout master
	git pull --rebase

	# ==============
	Setup to work on new branch / feature

	You are going to be doing one of two things before adding new changes:

	# 1. Connect to an existing remote branch
	# run the following to get the names of all local and remote branches
	git branch -la
	# creating a new branch from the remote branch (with tracking)
	# and checking it out locally
	# replace NEW_BRANCH with the remote name
	# example: remotes/origin/xyz_branch - use xyz_branch in place of NEW_BRANCH
	git checkout --track -b NEW_BRANCH origin/NEW_BRANCH

	# 2. Create a new branch with remote tracking
	# from master - run the following
	# we are creating a new branch and checking it out locally
	git checkout -b NEW_BRANCH
	# from NEW_BRANCH - run the following
	# this will create the remote branch
	git push -u origin NEW_BRANCH


	# ==============
	Daily Tasks

	# do lots of work with commits on NEW_BRANCH
	...
	# typical commands used, be careful not to add unwanted files
	git status
	git add --all
	git add FILE_PATH_FOR_SPECIFIC_FILE
	git commit -m "COMMIT_MESSAGE"

	NOTE: make sure all files are committed before preforming pull or push

	# get code changes from other developers, from the branch
	git pull --rebase
	# push your commits to github for other developers
	git push
	# you may receive rejected messages on some branches
	# that is ok if they are from branches other than your branch


	# ==============
	Merge feature branch into master

	# merge new code into master in 1 clean commit - squash all branch commits
	git checkout NEW_BRANCH
	git pull --rebase
	git checkout master
	git pull --rebase
	git merge --squash NEW_BRANCH
	git status
	git commit -m "feature NEW_BRANCH"
	# push changes to the master branch on github
	git push

	# delete topic branch locally and then the remote (if desired)
	git branch -d NEW_BRANCH
	git push origin :NEW_BRANCH


	# ==============
	Long lived local branches

	# if a long lived branch, pull in code from master using rebase
	git checkout master
	git pull --rebase
	# add these changes to branch with rebase so the history stays clean
	# do NOT do this if using a shared remote branch
	git checkout NEW_BRANCH
	git rebase master

	WARNING: do not squash commits or rebase branches that have been sent to a remote repository, this should not be an issue for local only branches.


	# ==============
	Hot-fixes

	# you fix a bug on the master branch
	# and now you want it integrated into the current dev branch
	git checkout NEW_BRANCH
	git cherry-pick -x master

	# this will pull in the last commit from the master branch
	# NOTE: the commit ID (SHA) is different, this is really a copy of the commit
	# Since it will get squashed merged back into master later it will look like no change
	# You can also use a commit ID in-place of 'master' or specify ranges of commits


	# ==============
	Other useful commands

	# interactive rebase to squash back to master
	git checkout NEW_BRANCH
	git rebase -i master

	# create a remote branch with tracking from current branch
	git push -u origin REMOTE_BRANCH

	# delete remote branch (named REMOTE_BRANCH in this example)
	# note there is nothing on left side of the colon
	# this means push nothing to the remote branch origin/REMOTE_BRANCH
	git push origin :REMOTE_BRANCH

	# create a tag; 1620 in this case, it could contain any non-space characters, i.e. 1620-fix1
	git tag -a 1620 -m "TAG_MESSAGE"
	git show 1620

	# push tags to remote
	git push --tags

	# summary of the last few commits
	git log -16 --format='%h %ad %d %an: %s' --date=short

view raw git-workflow.rb hosted with ❤ by GitHub

Resources

House 9

Friday, February 3, 2012

Git Workflow

Blog Archive

Subscriptions

Quote of the Day