0

I have a base develop branch, and create a new feature-a branch. When I'm finished I commit the changes and push, then make a merge request. While the results of that merge request are pending, I want to continue to work on a new feature-b branch, which extends code in the feature-a branch. Is this possible, and if so, how?

GluePear
  • 7,244
  • 20
  • 67
  • 120
  • 1
    https://stackoverflow.com/questions/36630971/correct-procedure-to-use-pending-branch-changes-in-a-new-branch – Josh Adams May 07 '18 at 13:32

1 Answers1

1

Yes, of course it is.

So lets say you work on feature-a just to make sure type

git co feature-a

to check you are on that branch you can type

git branch -a

so now you are 100% sure to be on the right branch then from there type:

git co -b feature-b

now you have the changes from feature-a you can do 

git log

to see the last changes from feature-a are here and you can do git branch -a to verify you are on the new branch called feature-b

The important thing #1 is when you create a "new" branch with git co -b new-branch-name it will have all commits from the branch you are currently on.

Then, the important thing #2 when you create the pull reuqest make sure to select the right "base" branch as that will not be set correctly automatically. It will also list all commits which are new, when you change to the right base branch you will see only the "desired" ones from the new branch.

caramba
  • 21,963
  • 19
  • 86
  • 127
  • 1
    Just make sure you also create a link/dependency on the issues in your bugtracking/project management system so that you don't release feature B before feature A, because the way git works, releasing feature B will implicitly pull with it feature A, regardless of the state of the branch for A. – Lasse V. Karlsen May 07 '18 at 13:36
  • In general it's best to avoid this sort of situation. Either you created some framework in branch A that you also want to use in branch B, in which case you should at least make a note of trying to organize things differently in the future, or you're actually extending A with new features, in which case I think you've organized your issues a bit oddly. There *will be* some slack after implementing an issue, with code reviews, pull requests, testing, etc. and if you need to continue working on the feature right away you might want to work differently altogether. – Lasse V. Karlsen May 07 '18 at 13:38
  • 1
    @LasseVågsætherKarlsen thanks for the comments. I've updated the answer. – caramba May 07 '18 at 13:40
  • Yup, my comments was more to the OP, your answer was perfect as it was. We do this ourselves, despite my advice to the contrary, but we try to minimize these cases as they start creating dependencies everywhere. "You can't release C before A, and you have to release B after C, but C was tested first and the customers want C, etc. etc." – Lasse V. Karlsen May 07 '18 at 13:49
  • @LasseVågsætherKarlsen true! I know. I need it mostly for my work. So I can try something, it's saved, coworkers can comment on it. It's always awesome as long as it doesn't get messed up :) – caramba May 07 '18 at 13:55