54

I'm new to git and git flow. I've read all the various pages, blogs, and stackoverflow questions on it,and have been using it in my daily development.

But one issue has been bothering me, I just can't wrap my head around it. I know feature branches are supposed to be small, you start a feature, code a part of it, then finish the feature. This is a daily occurence, I get that. We just make sure that our develop branch is always buildable.

But what happens when I'm in the middle of a feature, it isn't ready to be finished, but work priorities change? I'd like to be able to switch to another feature.

For example, I start a new feature.

$ git flow feature start yak-Speedup

I write code, commit files, etc... and am making good progress on it. But now I need to change what I am working on, mostly like because I need a resource that isn't available and the server coder won't have it ready for a day or two. I can't finish the feature because it will break the develop branch.

I'd like to do something like this:

$ git flow feature pause yak-Speedup
$ git flow feature start alpaca-Sheering
#write code
$ git flow feature finish alpaca-Sheering
$ git flow feature resume yak-Speedup

Indeed, the existence of the "git flow feature list" command implies that I can have several features going at the same time. But I don't see how to create or switch between features. Indeed, I'm starting to think that this isn't a git flow issue at all, but a git issue.

I appreciate any help. Thanks!

John Green
  • 543
  • 1
  • 4
  • 5

4 Answers4

52

You do not need the git flow feature pause yak-Speedup command (feature pause doesn't exist anyway). The command you want to use in place of git flow feature resume yak-Speedup is git flow feature checkout yak-Speedup; that will get you back on the yak-Speedup feature branch to continue development.

Executing git flow displays:

Try 'git flow <subcommand> help' for details.

And executing git flow feature help displays:

usage: git flow feature [list] [-v]
       git flow feature start [-F] <name> [<base>]
       git flow feature finish [-rFk] <name|nameprefix>
       git flow feature publish <name>
       git flow feature track <name>
       git flow feature diff [<name|nameprefix>]
       git flow feature rebase [-i] [<name|nameprefix>]
       git flow feature checkout [<name|nameprefix>]
       git flow feature pull <remote> [<name>]
Go Dan
  • 15,194
  • 6
  • 41
  • 65
  • 2
    that's great! I'm guessing there is no need at all to pause yak-Speedup. Just starting the alapca-Sheering is enough? – John Green Dec 21 '11 at 18:12
8

Late to the party, but my experience is this..I use git in combination with git flow..

git flow feature start foo  <<== start
#code, hack and COMMIT
git checkout develop        <<== go back to develop branch.. 
git flow feature start foo2 <<== start a new feature
#code, hack and COMMIT
git checkout feature/foo    <<== go back to foo. NB: using full branch name

By going back to develop i ensure that I am branching independently from foo and using develop only. I can also do any merging of develop if there has been commits from other features at the time as well....

angryITguy
  • 9,332
  • 8
  • 54
  • 82
  • 4
    FYI: there's `git checkout feature/foobar` and `git flow feature checkout foobar` which.. do the same. The difference is that with plain git command, you need to write `feature/` and you get tab-key-autocompletion of branch name (hopefully). With `flow feature checkout` instead you get a silent automatic prefix-lookup: `git flow feature checkout foo` is enough and it will fetch the `foobar` feature branch. No big deal, but imagine having to find/write/autocomplete branch names like `WTF1234_Adding_new_db_layer every time`. With flow, `checkout WTF1234`. – quetzalcoatl Apr 19 '17 at 13:07
0

What you want are really branches:

git branch feature1 <startingpoint>
git checkout feature1
# hack hack hack, commit commit commit
git branch feature2 <startingpoint>
git checkout feature2
# hack hack hack, commit commit commit
# Oops, urgent request comming in, must switch to stable and patch
git stash
git checkout stable
# patch, commit, push
# back to feature2
git checkout feature2
git stash pop

etc etc. Branches are made for that.

And once you know your feature is good, merge into dev and push.

fge
  • 119,121
  • 33
  • 254
  • 329
  • 2
    how does that work with git flow tools? Can git flow handle that? Or do I just ignore the git flow tools at this point. Git flow really is just branches... – John Green Dec 20 '11 at 20:42
  • this ties feature1 to feature2. In other words, it is no longer trivial to ship without feature1 in case you decide against it but still want feature2. – Adam Dymitruk Dec 20 '11 at 20:46
  • 1
    Eh? Just merge only what you want in `dev`, there are no ties of any kind here! – fge Dec 20 '11 at 20:47
  • feature1 is in the history of feature2. – Adam Dymitruk Dec 20 '11 at 21:06
  • 4
    Uhhh, the bickering might make you feel good but it doesn't help answer the question. Sorry to be so blunt, but I'm trying to learn here. One truism I've discovered with git is that it is powerful and complicated. The above exchange proves that. I have two experts who disagree where feature2 is branched from. How is a newbie supposed to understand that? – John Green Dec 21 '11 at 12:34
  • @fge - thanks for the example, how do your example work with git flow? I still don't get it. – John Green Dec 21 '11 at 12:34
  • Well, OK, that becomes a conflict in methods at this point: I see no interest in git-flow. Git proper offers sufficiently powerful tools to handle all cases, especially since for regression testing there is `git bisect`. I rely on the latter heavily, and know whom to blame when something goes wrong :) _And_ it is automated via `git bisect run` if a problem appears. – fge Dec 21 '11 at 13:06
  • hm.. now it's few years later, I hope you have some time to try out how git-flow helps in doing just the same thing using less number of commands just to switch back and forth, and, hey, you can still use `bisect` as well - in context of release, develop or specific feature - what actually makes it easier to pinpoint the problem – quetzalcoatl Apr 19 '17 at 13:02
0

Use a more explicit model. This is git flow improved with no extra commands:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

The important thing here is that you would not start feature2 off of feature1.

Hope this helps.

UPDATE

I've blogged about this. Hope it's a little clearer:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 3
    I'm sorry Adam, I've read that as part of my research into this, and I've just reread it. I don't understand what you are trying to say. Maybe it is brilliant, but it isn't clear what you are trying to accomplish. If you want your idea to be as accepted, you need to write as clearly as nvie, Kreefmeijer, and especially as clear as Yakiloo. – John Green Dec 21 '11 at 12:37
  • Yes it is rough, but needed to put it down at the time. The key is that you can recreate a branch (we call it the QA branch) to assemble features that are good enough for production. If you don't want a feature, you simply delete the branch and recreate it by merging the features you want - omitting the ones you don't. You can't do that if you make feature2 start somewhere in feature1. – Adam Dymitruk Dec 21 '11 at 15:55
  • When I get time, I'll put up an illustrated post. – Adam Dymitruk Dec 21 '11 at 15:55
  • Making feature2 not part of feature1 is something I very much want to avoid! – John Green Dec 21 '11 at 16:05
  • it definitely depends on if your project is just starting. At the beginning, most of it is plumbing - not features. So you will have tightly coupled features. As you progress in your project and are doing less plumbing, you can have them independent of one another. Usually, not adhering to OCP (Open Close Principle) and other S.O.L.I.D. practices leads to coupling that can make BpF hard. – Adam Dymitruk Dec 21 '11 at 16:21