Git rebasing branches

Question

I am managing a git repository and only have write access on the master branch. I have asked my colleague to create his own branch and push any changes to that branch and I will rebase them onto master. Now here's my scenarios:

My colleague checks out branch A and makes several commits. I continue working on master branch. Colleague pushes changes to the repository and I rebase them onto master. I keep working on master branch while my colleague keeps working on A.

Now, my question is whether colleague needs to delete A after the rebase and create a new branch or can he keep working on A? Does he need to merge the new master with A before continuing to work after the rebase?

A
| \
|  \
B   D
|   |
C   E
|  /|
H / F
|   |
I   G

Edit in response to Tim's answer for formatting:

This is not my scenario though. branchA never integrates changes from master. So basically:

master:      ... A -- B
branchA:    ... A -- C

and then:

master:      ... A -- B -- C'
branchA     ... A -- C

Note branchA remains unchanged. Is it now safe to continue working on branchA?

Answer 1

Your colleague should be able to keep using the same branch after you fast forward master with the changes from branchA. The reason for this is that, immediately after your colleague finishes a rebase of branchA on master and fast forwards master with its own commits, these two branches should be identical at that point in time. Note that this is sort of the opposite situation of what happens after synching up via a merge, in which case you would most likely want to delete the feature branch and branch out again with a new branch.

Consider the following simple workflow, which uses rebasing:

master:  ... A
branchA: ... A

Both master and branchA each get a commit:

master:  ... A -- B
branchA: ... A -- C

Now branchA rebases on master:

master:  ... A -- B
branchA: ... A -- B -- C'

Note that I have labelled the unique commit of branchA above with an apostrophe, because it is a new commit, which however would probably closely resemble the original commit C.

Now, we fast forward master with the changes from branchA. We can do this because after the rebase branchA is ahead of master. This leaves us with:

master:  ... A -- B -- C'
branchA: ... A -- B -- C'

And at this exact moment, both featureA and master are in lock step with each other. We can rinse and repeat, because we are now essentially back where we started.