Need changes from branch A not committed to master, being now on branch B

Question

I am unable to find a solution to my Git & branching issue nor I am able to properly search for it.

Namely, all tutorials on branching show ideal situation: you create and work on branch, commit and merge to master, create a new branch,...

In real time, this is not happening. In my case, a person who handles merging to Master (via pull requests) is on leave for 7 days. In that time I have to work on 10 tasks.

So, I take Task 1 and create a branch task-1-branch and do the task. Then commit the branch to the remote repo.

Now I want to work on Task 2. I need to create task-2-branch, but where?

Do I branch from the Master or Task 1 branch?

How can I have changes I made in Task 1 branch in the Task 2 branch without merging it?

And lastly, if I create subbranch from Task 1 branch, will that affect Pull Request eg confuse a guy who handles merging to Master?

Answer 1

Do I branch from the Master or Task 1 branch?

This depends on whether you need the changes from the task1 branch to be able to work on task2.

If you can work on task2 without needing the commits from task1, branch from master. Then task2 can be merged even if task1 isn't merged first.

If task2 builds upon the changes introduced in task1, branch from task1. In this situation, it wouldn't make sense to merge task2 without task1. You can work on task1 and task2 separately, and they can be reviewed for merge separately, but task2 can't be merged without task1.

In the second situation, it might happen that some changes need to be made to task1 before it can be merged. If that's the case, you can then update the task2 branch with the more recent changes to task1:

git checkout task2
git merge task1

Then you can resolve the conflicts (if any) and push to the remote copy of task2.

Answer 2

Workaround for "master guy is on vacation"

You can do this, now:

• First, let master alone.
• Have one separate feature branch for every one of your tasks (like you already explained). All of those should branch out from master .
• Now the magic: you can create a third branch, let's call it qa . Also branching off of master . Now you merge all your feature branches, when done, into the qa branch. Whatever you wanted to with master , but can't yet, you do with qa . Ie, you can run your test suite against qa to see if there is any interaction between your tasks that is going wrong. If something goes wrong, or if you had to change one of the task branches, just delete qa and start over (by branching qa off of master again and then adding in all your task branches in the same order as before).
• When the person able to pull into master is back, you can either hand over your individual task branches, or the qa in all its glory; functionally, it will be the same, just less work for him. You'll have to ask him how he wants it to be.

This can be extended to a full-fledged workflow: http://dymitruk.com/blog/2012/02/05/branch-per-feature

Sub-branch

Best avoid these. Nothing intrinsically bad about it, it just adds a bit of complication/error potential.

That said:

If you have a branchB which contains branchA , then he can either pull branchA , then branchB , or he can pull only branchB . Results will be the same.

In any case, after you branch branchB off of branchA , you better make sure you don't touch branchA again, or chaos will likely ensue (for obvious reasons, ask if it's unclear what I mean).