Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Git workflow

No description
by

Chris Auer

on 10 July 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Git workflow

feature branch
dev branch
release branch
master branch
hotfix branch
dev branch
dev branch
should be used as an
"integration branch"
dev branch contains code that is feature complete and ready to be
tested by QA
So where should I commit changes that aren't ready for the release process?
feature branches
feature/myfeature
dev branch
QA should begin testing
the new release branch
release branch
Minor bug fixes can be committed to release branch, will later be merged back into dev
Finishing off a release
after QA has verified/minor bug fixes are committed...
git flow:
git flow release finish VERSION
git cli part 1:
git checkout master
git merge --no-ff release/VERSION
git tag -a VERSION
git cli part 2:
git checkout dev
git merge --no-ff release/VERSION
git branch -d release/VERSION
master branch
Master branch,
it's where the
prod environment is at
When there is a issue
in production that needs to get fixed right away, we use the
hotfix branch
hotfix branch
Track down the issue and
commit fix directly to the
hotfix branch
git flow:
git flow hotfix start VERSION

git cli:
git checkout -b hotfix/VERSION master
QA should test the hotfix branch
before its merged back
into master
git flow:
git flow hotfix finish VERSION

git cli:
git checkout master
git merge --no-ff hotfix/VERSION
git tag -a VERSION
git checkout dev
git merge --no-ff hotfix/VERSION
What is git?
Distributed Version Control System
Distributed
vs.
Central
Repository
Server
only files
only files
"origin"
full repository
full repository
full repository
full repository
Linus Torvalds
(original git creator)
Extremely efficient
Encourages distributed development
but...
DO NOT ANGER THIS MAN
OR YOU WILL GET HURT
Extremely efficient
Encourages distributed development
but...
DO NOT ANGER THIS TOOL
OR YOU WILL GET HURT
Git source control
Git basics
Starting work on a repository
$ git clone <path to repo>
(creates a copy of existing repository)
Never cloned a repository before?
Don't worry!
Additional resources to help you:
http://jobseeker.com/
http://www.indeed.com/
$ git status

Shows you which files have changed, which files aren't tracked yet, and which files are staged
$ git add
vs
$ git commit

git add will stage changes for committing
$ git push
vs
$ git pull

sync between your repository and a remote repository
$ git checkout -b <branch>

Switching between/creating branches
$ git stash
vs
$ git stash pop




"Stash" away all your stage
changes to allow you to
return back to HEAD

$ git merge <branch>

merge a branch onto the branch you currently have checked out
This guy doesn't know what he is talking about...
Blah, blah, blah...
"Torvalds has quipped about the name git, which is British English slang roughly equivalent to "unpleasant person". Torvalds said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
branched from dev branch, and typically exist on developers local repository only
Should be short-lived, ideally 1-2 weeks max
What if your feature will take more than 1-2 weeks to develop?
Strategy for "long-lived" branches
Break your feature down into smaller pieces
Feature Toggles
So how do I create a feature branch?
git flow:
git flow feature start myfeature
regular git cli:
git checkout -b feature/myfeature dev
Commit as frequently as you would like.
git flow & git cli:
git add <file changed>
git commit -m "commit message"
Pushing your branch to origin for collaboration/backup
git cli:
git push origin feature/myfeature
git flow:
git flow feature publish myfeature
Finishing a
feature branch off (merging it back into dev)
git flow:
git flow feature finish myfeature
git push origin dev
git cli:
git checkout dev
git merge --no-ff feature/myfeature
git branch -d feature/myfeature
git push origin dev
Feature branch is now merged
with dev, Dev should be stable code!
What does the release process look like then?
git flow:
git flow release start VERSION
git flow release publish VERSION
git cli:
git checkout dev
git pull origin dev
git checkout -b release/VERSION dev
git push origin release/VERSION
Full transcript