2

On an actively developed project, the master has a model called FollowingModel.

I branched off from the master and worked on my branch for a few days - creating methods which used the FollowingModel. By the time I made a PR,another branch was merged into master which changed the FollowingModel to Following. I could merge into the master without a merge conflict, but the application would break if I did so - since my methods would be calling a model which has it's name changed.

What is the correct way to proceed in situations like this? In a big project, where there are a lot of moving parts, how is this taken care of?

Darshan Chaudhary
  • 2,093
  • 3
  • 23
  • 42

2 Answers2

1

You need to rebase your local branch on top of the new master before submitting your PR.

  • You fetch from "upstream" (the remote referencing the original repo),
  • merge upstream/master to master in order to update your own master,
  • rebase your branch on top of master and force push (and adapt the your method name to what master is using)

The goal remains for the maintainer to be able to fast-forward your branch on top of his/her master branch when receiving your PR.

If you are pushing directly to the original repo, then:

Did you know you can use Pull Requests between branches, on the same repository?
You don't need to fork repositories to use Pull Requests.
Internally at GitHub, we almost always use Pull Requests between branches.

  • the sequence becomes:

    git checkout master
git pull origin master
git checkout featureBranch
git rebase master
# fix bugs
git push --force origin newBranch

But that supposes you are the only one working on newBranch (or this is the first push of newBranch). If you do that several time, the history of newBranch changes at each force push.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • so, `git pull origin origin/master; git checkout featureBranch; git merge origin/master;`, fix bugs, `git push origin featureBranch`? – Darshan Chaudhary Jul 01 '16 at 06:20
  • @DarshanChaudhary No: origin is your fork, it does not reflect the latest from the original repo. Add a remote "upstream" with the url pointing to that original repo. `git remote add upstream /url/to/original/repo` – VonC Jul 01 '16 at 06:21
  • (my `origin` is my `upstream`, I am pushing to the original repo, on a different branch which is merged into `master` after code review). I understand your suggestion is - `git checkout master; git pull origin master; git checkout featureBranch; git rebase master;`, fix bugs, `git push origin newBranch`? – Darshan Chaudhary Jul 01 '16 at 06:27
  • @DarshanChaudhary in that case, yes, but then it is not a "PR". – VonC Jul 01 '16 at 06:29
  • (I raise a PR which requests my featureBranch to be merged into `master`, what else can it be called?) Also,in this case, won't my `newBranch` have commits which aren't related to my feature at all? – Darshan Chaudhary Jul 01 '16 at 06:32
  • @DarshanChaudhary "in this case, won't my newBranch have commits which aren't related to my feature at all" not is your newBranch is dedicated to develop only your feature: by rebasing it, you don't include any unrelated commit, you change its base (while validating that its focused content is still working when applied on top of an updated history). – VonC Jul 01 '16 at 06:33
  • @DarshanChaudhary A PR is generally done from a fork (http://stackoverflow.com/a/36119218/6309) – VonC Jul 01 '16 at 06:35
  • (Github still calls it a PR!) Makes sense, Github will see that some of the commits I am pushing are already merged and skip over them, publishing only the new commits from the `newBranch`. Am I correct? – Darshan Chaudhary Jul 01 '16 at 06:37
  • 1
    @DarshanChaudhary True, I forgotten that. I have edited the answer to point out you can make PR from the same repo (no fork required) – VonC Jul 01 '16 at 06:46
1

The thing you'd normally do before merging back is rebasing on master. And thats what you should do in this situation, either rebasing or merging master back into your branch. After that, you have the new master-changes in your branch and can fix all problems which arise. After fixing all the bugs, you can merge into master.

tkausl
  • 13,686
  • 2
  • 33
  • 50
  • So, i) rebase feature branch on the master, fix the bugs and `git merge`, push the master branch to a remote repo? Where should I push it, to a new branch on the remote repo? ii) merge the master branch into feature branch, fix bugs, push the feature branch to remote repo. Won't this lead to duplication of git commits and lead me to have commits that aren't related to my feature in my branch? – Darshan Chaudhary Jul 01 '16 at 06:18
  • Both ways are okay. Either rebase or merge, doesn't really matter, what matters is, that you have the changes in master in your branch. Not sure what you with the last sentence mean, but yes, you'll have a merge-commit when you merge, you won't have one when you rebase, but rebase will re-write your whole branch-history on your feature-branch. – tkausl Jul 01 '16 at 06:22
  • Isn't rebasing the master on the feature branch a better idea than the other way around? That way, I will have the commits from the master branch, I can rewrite their history by rebasing and push them to the same branch on the remote repo – Darshan Chaudhary Jul 01 '16 at 06:35
  • Yes, thats what I actually meant, but I call it "rebase feature branch on master" and you call it "rebase master on feature", not sure which one is correct. In the end, you should have a feature-branch which looks like as if it were branched out from the master-branch directly, not a commit in masters history. – tkausl Jul 01 '16 at 07:05