0

So currently I am on a feature branch (let's say f1) and the develop branch is ahead of f1.
Another developer is developing a new feature f2 and commits to the develop branch. Now the develop branch has the feature f2 plus other features that are not in f1.
Now I want to test only the feature f2 without all other features that are on develop but not in my branch f1. How can I achieve that?

Important: After I finish my test, I want f2 to be out of my f1 branch.

Now I'm doing this in the following way:

  1. stash all my unchanged changes (git stash), because I'm not sure I want to commit them
  2. cherry pick the commit in f2 (git cherry-pick f2)
  3. unstash (git stash pop)
  4. test
  5. stash all my unchanged changes (git stash)
  6. revert cherry-picked commit on f1
  7. unstash the uncommited changes
  8. commit on f1 if all the changes are ok

Is there a better way to do this?

Edwin
  • 2,146
  • 20
  • 26
  • I'm kind of confused. At first, you ask "How can I get the commits from `f2` to my branch?" which has a simple answer, namely cherry-pick the commits. Then you describe the steps you have taken which is much more than that: You check if your branch `f1` **plus** the uncommitted changes on your branch **plus** the cherry-picked commits from `f2` pass a not further specified test and if so, you cleanup your branch again and commit your changes... Those are totally different things. But in case that is what you want to do, the steps are fine. But don't revert, drop the commit via rebase instead. – Michael H. Aug 15 '18 at 10:10
  • I never said that I want the commits from `f2` in my `f1` branch, I just want to test the `f2` on the `f1` branch. Imagine the `f2` branch files as unstaged files in `f1`. The steps are what I am doing right now (doesn't mean they are the correct steps to follow), but I'm looking for a better/faster and less error prone solution. The unstaged files are there, because I am not sure if I need this changes or not, only after the test I will know, therefore makes no sens for me to commit them before the cherry pick. – Edwin Aug 15 '18 at 10:15
  • I don't think there is a simpler solution. Only thing I can think of is committing your changes to a new branch `f1-test` and cherry-pick `f2` to that branch. That way you don't have to stash/unstash all the time. But that makes it a bit harder to get the previously uncommitted changes back to `f1` afterwards. So you effectively win nothing. – Michael H. Aug 15 '18 at 10:20
  • I thought maybe the git-flow has a feature to handle that or maybe is there an easier way than mine in git. – Edwin Aug 15 '18 at 10:22
  • 1
    Not to my knowledge, but maybe someone else here can think of an easier solution. If you're used to git, your way is not very error prone ;-) In case you ever break something (like losing changes you made), check out git reflog. – Michael H. Aug 15 '18 at 10:25
  • in the end I think this can help my flow: https://stackoverflow.com/questions/32333383/git-cherry-pick-to-working-copy-without-commit `git cherry-pick -n` and then I would not need to uncommit the stuff. I'm not sure about the stashing, but I will try it next time. – Edwin Aug 15 '18 at 13:24
  • But this will make it impossible for git to know what inside the stash is from you and what is from f2, right? – Michael H. Aug 15 '18 at 17:16
  • I mean, you will know, you can stash f1 with a label f1, then cherry-pick from f2 and then you can stash show to see the diff. Then depends on you how you want to act (for more see docs on stash). – Edwin Aug 15 '18 at 19:55

1 Answers1

1

Two things I notice:

  1. You appear to be thinking of F1 as being only those commits which you have added to the branch
  2. You are, as a result, trying to keep the F1 branch "clean" by actively preventing any code you didn't create for that feature from being part of the F1 branch

The reason this is causing difficulty is you're actually working somewhat against both the git model and how git flow is intended to work.

To address the first issue, a branch (in git's brain) is just a label pointing to a commit, and the branch contains that commit, its parent(s), and its parents' parent(s), etc. all the way back to the initial commit. So your branch isn't "my code" it's "the project history, plus my code."

When using git flow, develop becomes the defacto master branch for the development team. So essentially, once something has been merged into develop it's the "official" code of the project even though it has not been released.

So if F2 F3 and F7 have all been merged into develop, testing F1 with only F2 will never be able to give you a complete picture of how your code will integrate into the main line code.

To continue our reasoning, in your situation, instead of your branch containing "the project history, plus my code" it contains "some outdated version of the project history, plus my code." To use a somewhat flawed analogy, you're designing an car cover for a 2018 Mustang by bolting the 2018 fender onto a 1977 Mustang and hoping for the best.

The recommended mechanism for preventing your feature from becoming out of date is to regularly either merge develop into your feature branch, or to rebase your feature branch onto the new head of develop (depending on if you've shared your code and the workflow preferences of your team). The developer of the feature branch is always responsible for resolving conflicts and ensuring integrity of the features already merged to develop.

Addendum

As you've stated that keeping your branch clean is a team requirement, rebase is your new best friend.

$ git checkout F1
$ git fetch
$ git rebase origin/develop

This will fulfill the team requirement to keep your commits together and your branch "clean" from a history perspective while allowing you to test against all code added to develop after you created your branch. All without the dance and the need to roll things back.

LightBender
  • 4,046
  • 1
  • 15
  • 31
  • this is nice and dandy, but I work on a big project and I kindly disagree with your view. Some features are unrelated with my "part", also some other parts of the project may not be yet ready (not yet in develop), so instead of fighting with some code from other features, that maybe the configuration is not yet commited or god knows what is happening there, I will try to keep the project working as it is and keep the feature branches "clean" and not merge the feature between them or with dev, so that you can have a clear view of what exactly one feature contains. Plus this is the project rule. – Edwin Aug 15 '18 at 12:32
  • I may have been unclear, but I'm not talking about trying to integrate with anything that hasn't been added to develop. The more developers there are involved and the more features that are integrated on a daily basis, the more important keeping everything up to date becomes. Now that I've got a little more information about your team's workflow, I have update my answer with a more concrete prescription. – LightBender Aug 15 '18 at 12:59
  • actually I think I found my answer here: https://stackoverflow.com/questions/32333383/git-cherry-pick-to-working-copy-without-commit I can do a `git cherry-pick -n` and then I don't need to rebase or do anything else. – Edwin Aug 15 '18 at 13:22
  • 1
    @Edwin My concern is that because your approach is against model, you are opening yourself up to doing a lot of things manually that git handles automatically if you work within its logical model. Just one example, a no commit cherry pick will mix the code from `F2` into `F1` changes already in your working directory. You would then need to manually separate the salt and pepper which is a lot more work than just using one of the native tools git provides specifically for integrating approved code into unapproved branches. That being said, give it a try, it could work perfectly for you. – LightBender Aug 15 '18 at 14:18
  • sure it can go wrong merging and so on, but that's the reason I'm stashing my stuff first and then do the cherry-pick and then I can use stash functionallity to integrate my untracked files. What you are doing isn't enough for my case, but maybe in other cases this is the solution. – Edwin Aug 15 '18 at 14:23