19

Lets say I've created a new feature with git flow feature start FEATURENAME

then published it with git flow feature publish FEATURENAME

Now my colleague wants to collaborate on this feature with me, so he does

git flow feature pull FEATURENAME

This creates a new branch on his local repo, based on the feature branch in the remote repo. This does not however set his local feature branch to track the remote feature branch, so now he has to track this branch manually.

What is the reasoning behind this extra step? Why not have the feature pull command set to track as well?

What's the workflow difference between git flow feature pull and git flow feature track.

In which cases would you use each of those?

OpherV
  • 6,787
  • 6
  • 36
  • 55
  • It becomes even more confusing if your colleague does a ```git pull``` before ```feature pull```. – dashesy Jan 04 '14 at 19:25
  • I want to use ```git-flow``` but I need to also sort out how to do the *feature collaboration* part, so will set a bounty for this, hopefully to get a better idea. – dashesy Jan 04 '14 at 19:28

2 Answers2

17

Sounds like you are using git flow feature pull, where you should be using git flow feature track, since that does create a local branch that tracks the remote.

I can't really think of why I'd ever use git flow feature pull. It creates a local branch with no tracking set up on it, and I don't know why that would be useful! It's also badly named, since a pull should involve a merge, and this does not.

naomi
  • 1,934
  • 1
  • 14
  • 29
13

This answer by brainimus illustrates the collaborative aspect of a feature branch, using the GitHub pull request aspect which facilitates the code review and discussion part:

  1. Create a feature branch: git flow feature start module_1
  2. The code is updated on the feature branch
  3. As changes are committed they are pushed to GitHub (or once at the end if preferred)
  4. When the feature is completed a pull request is opened in GitHub comparing develop and the feature branch module_1
  5. The team reviews the pull request and makes comments
  6. Any changes from the pull request are made to the feature branch
  7. Once all changes are incorporated on the feature branch the feature branch is finished: git flow feature finish module_1
  8. The develop branch is pushed to GitHub (GitHub will automatically mark the pull request as closed/merged when this happens)

That leaves the issue of closing that branch though:

Who ever runs git flow feature finish module_1 will have the luxury of their local feature branch being deleted but anyone else who checked out the branch with have to do this manually if they want to

I would recommend a git fetch --prune, especially since Git 1.8.5 you can set that "prune" step in your config: a simple git fetch will remove your feature branch if it has been deleted on the server side (by someone else making a git flow feature finish)

The gitflow feature track if the AVH edition simply checkout and track the branch, that is make sure the local branch becomes a local tracking branch, with an upstream branch (a remote tracking branch) associated to it.
That is, it sets up branch.<name>.remote and branch.<name>.merge.

If you do a git flow feature pull (for a new local feature branch), but meant actually git flow feature track, all you would need to do would be to make your existing branch track the upstream one:

git branch -u origin/feature

Generally:

  • you start with git flow feature track,
  • then you keep your local feature branch up-to-date with git flow feature pull
  • you switch between feature branches with git flow feature checkout

As mention in "Getting Started – Git-Flow":

git flow feature pull

This will be done when more than one person works on a feature together.
You should use this command if you want to do a pull on the remote feature branch as follows:

git flow feature pull [alias] [featureName]

By using this command you’ll get the source code that has been pushed by your team mates and their changes will be automatically merged into your local branch.
If there are conflicts you will be the unlucky or lucky one to do the resolutions of these conflicts.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Also any advice to use the official git-flow, or the AVH Edition?
    I recently got confused with feature branches getting diverged after ```git pull```, and want to put in place some procedure for our team.     – dashesy Jan 05 '14 at 01:45
  • @dashesy I detailed the differences between `gitflow feature branch [pull, track, checkout]` – VonC Jan 05 '14 at 09:09
  • 1
    @VonC This does not really address the question of why would one ever want to `pull` instead of `track` (and by now with experience I've reached the conclusion that there's no real reason to do `pull`). Part one of your answer has nothing to do with the topic at all. Regarding the second part - there is no `gitflow feature push` command. – OpherV Jan 05 '14 at 17:26
  • @dashesy a bit offtopic but I've had much better experience with the AVH edition, which is still maintained today. Looks like nvie stopped taking care of the original git flow repo, as the last update is over a year ago and has ~200 outstanding issues and ~60 pull requests. – OpherV Jan 05 '14 at 17:28
  • 1
    @OpherV sorry for the typo: I meant pull not push. Once you have tracked, you can do `gitflow feature pull` to keep your local branch up-to-date. And I do reference the AVH one. – VonC Jan 05 '14 at 17:31
  • @OpherV I have added a section to explain the `git flow feature pull` command usage. – VonC Jan 05 '14 at 17:37
  • Actually, if you already have a feature branch tracked, you can just `git pull`. No need for the longer, more cumbersome `git flow feature pull [alias] [featureName]` :) – OpherV Jan 05 '14 at 17:48
  • @OpherV not sure, if you read the "Getting Started – Git-Flow": " if you do a pull from the feature branch with the normal “git pull” command it breaks your HEAD and for some reason it’s very hard to get back to a point where you would be able to push any changes made or even do a feature pull in the future." He adds: "My advice when working with Gitflow is to use its commands wherever possible. " – VonC Jan 05 '14 at 17:50
  • @VonC thanks for the update, yes the key seems to start with ```feature track```. – dashesy Jan 05 '14 at 19:59
  • @OpherV Yes, the AVH edition also has bash completion that helps a lot, and seems to be better maintained. If for example ```feature pull``` is going to ever be fixed to ```track```, the AVH edition seems better place to file an issue. – dashesy Jan 05 '14 at 20:02
  • serious question did nvie stop developing or is it done ? – krystan honour Jan 12 '16 at 12:53
  • 1
    @krystanhonour https://github.com/nvie/gitflow/pull/419/files => https://github.com/petervanderdoes/gitflow – VonC Jan 12 '16 at 12:59