Reputation: 410
I'm working with some guys on a bitbucket repo.
We have a instruction that merges to master are done only through PR's.
I have a branch in my local repo, which i derive from a commit in my local master. That commit is not yet in the remote master.
If i push my branch to the remote and i request a PR into master.
Which commit will it be merged to? or it is just moved to the tip of remote master?
Let me add this
Local repo
A <--- B <--- C
Remote repo
A <--- B <--- C
But we cannot push to master branch
So, I make a change to my local git master branch as this
A <--- B <--- C <--- D
I know i shouldn't have made that change and so, i'll probably have to check a new branch like
git checkout -b master-to-merge
And push that branch to be merged into remote master.
But my question is:
Assuming I have a branch like so
A <--- B <--- C <--- D
\
\
E <--- F <--- G
I name the branch; feature-branch. If I push that feature branch to the remote repo to be merged into master. Since commit D is not in that repo, which commit will be the parent of the my feature-branch?
Upvotes: 0
Views: 89
Reputation: 45819
UPDATE - based on your edit to your question, it appears you are specifically looking for phrasing I didn't use. I didn't use it for a reason (it would be inaccurate language). Here is why:
A branch does not have a parent commit. A branch is a ref - i.e. a pointer to a single commit, not a collection of commits. Other commits might be reachable from a branch (by parent pointers), but that's all the relationship there is. Looking at an existing set of commits, you cannot tell where a branch was created. Based on commit topology and typical usage patterns, you can guess; but whether your guess is right or wrong has no consequence.
So while your question is trying to be very precise, in terms of git concepts it is actually very imprecise; which is why I won't try to translate my answer into those terms. This answer is precisely what the result will look like if you execute the PR; no more, no less.
Ok, so your current situation is
A --- B <--(origin/master)
\
C <--(master)
\
D --- E <--(branch)
You push branch
, then you have
A --- B <--(origin/master)
\
C <--(master)
\
D --- E <--(branch)(origin/branch)
Note that unless you push master
, neither the server nor any other clone is aware that you have master
at C
. From their perspective, then, it appears that C
is part of branch
.
(coworker's repo)
A --- B <--(master)
\
C -- D --- E <--(branch)
Whether you should push master
depends on your team practices. If master is meant to be updated by PR, then I would assume not. (I would also suggest that, in that case, you shouldn't really have a local change "on master".)
So I would expect the PR to resolve like this:
A --- B ------------ M <--(origin/master)
\ /
C -- D --- E <--(origin/branch)
Back in your local, after a fetch you would see
A --- B ---------------- M <--(origin/master)
\ /
C <--(master) /
\ /
D -------- E <--(branch)(origin/branch)
which at first glance seems a little messy, but actually you can just fast-forward your local master
to origin/master
(in fact I believe that's what a pull
would do by default), giving you
A --- B ------------ M <--(master)(origin/master)
\ /
C -- D --- E <--(branch)(origin/branch)
And now everyone agrees that C
is just like another commit at the beginning of branch
. The merge parent is B
, and the merge brings in C
through E
.
Upvotes: 1
Reputation: 443
You can simply push it to remote branch.
If you will create PR after merge on master PR will contain only your new commit. If you will create PR before merge on master PR should contain both commits.
I've tested it a bit:
some changes in repo
git add -a
git commit -m "master commit"
git checkout -b test-branch
some changes in repo
git add -a
git commit -m "commit on branch"
git push origin test-branch
PR:
and then:
git checkout master
git push
PR:
Upvotes: 0