2

I have something of an annoyance in my Git workflow. I do the usual thing where I branch off master, into a branch called feature. I work on this feature branch for a while, meanwhile possibly master has commits of its own, which I might merge into feature. As I do this, I have a remote branch for feature (origin/feature) that I use so I can build and run my code on multiple machines.

Now, when I finish with the feature branch, I need to push the code to our code review system. This means rebasing feature off master, and squashing all the commits into one. I do this, resolve conflicts if necessary, great. Here's the problem: feature and origin/feature now have different histories, and I'm not able to push. I tried push with -f to force it even, and this did not work either.

Is there some convenient way to rebase feature off master, and keep feature and origin/feature synced? What I'm considering is doing another branch for the code review. In other words, before the rebase and squash, branch into featurecodereview. Then rebase featurecodereview off master, and if I like I can push this upstream to a new remote branch. I was wondering if there was something cleaner than opening another branch.

Improve this question
5
  • recommended reading: Where does my git question go?
    – gnat
    Apr 9, 2014 at 14:56
  • 1
    This is a question is also about git workflow, there wasn't any code in my question, and there's a good chance the answer will be more focused on what the workflow should look like, as opposed to some magical flag or command. There seems to be a population of people that go after every question on SO and PSE that's grey zone and criticize the person for posting it there. Don't you have something better to do?
    – Nir Friedman
    Apr 9, 2014 at 15:05
  • What error do you get when you force the push? Are you using one of the following forms?: git push origin +feature or git push -f origin feature
    – jkyako
    Apr 9, 2014 at 21:00
  • I'd already set the upstream branch, so I just use git push -f. I get this message:
    – Nir Friedman
    Apr 10, 2014 at 15:13
  • git push -f X11 forwarding request failed on channel 0 Counting objects: 19, done. Delta compression using up to 8 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (10/10), 4.13 KiB, done. Total 10 (delta 3), reused 2 (delta 0) remote: + refs/heads/pipelinetutorial qr_lib nfriedman DENIED by refs/.* remote: error: hook declined to update refs/heads/pipelinetutorial To ssh://infragitd@infragit/qr_lib.git ! [remote rejected] pipelinetutorial -> pipelinetutorial (hook declined) error: failed to push some refs to 'ssh://infragitd@infragit/qr_lib.git'
    – Nir Friedman
    Apr 10, 2014 at 15:13

1 Answer 1

Reset to default
1

What code review tool/system are you using? Because git does have ways to show the diff (or create a patch, I think) across multiple commits. So rebasing and squashing may be completely unnecessary.

I also use a feature branch workflow, and I never bother with either. I just do a pull request (either in Github or Atlassian Stash) and it shows all the differences as if it had been a single commit.

Improve this answer
2
  • Hi, the tool I'm using is gerrit. Rebasing is necessary because when the commit passes review and gets merged into the codebase, it has to be a fast forward merge. The code review system will not take a chance doing any any other kind of merge. Squashing is ncecessary because if you push the rebased branch with multiple commits, it will actually show as multiple tickets in the code review system. Sometimes this is what you want, but usually you want the changes in your feature branch to be considered altogether. Hope that clarifies why rebasing and squashing is necessary.
    – Nir Friedman
    Apr 9, 2014 at 15:10
  • You should probably add that info to your question then; people with gerrit experience may be able to give better guidance. But off hand, it sounds like gerrit is the problem by not being smart enough to handle multiple commits or merge conflicts. FYI: Stash (which I use most frequently) shows a message in the pull request if it can't merge cleanly so you can resolve it yourself. Any additional pushes you make to the branch are automatically part of the open pull request. I think Github does the same.
    – Allan
    Apr 9, 2014 at 22:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.