1

We have a situation since we are using remote branches with Git. Let me explain briefly:

  • Developer John created a remote branch "post_video"
  • I checked out this remote branch to work on it too

    git checkout feature/post_video
    
  • I committed my changes (locally) and pulled out the changes on this remote branch from remote server:

    ... few changes ...
    git add myfile.html otherfile.js etc.
    git commit (+ message)
    git pull
    
  • Here came the first problem: when I pulled this remote branch, I had many conflicts but for files I never changed!

  • Second problem: after fixing these conflicts, I wanted to merge this remote branch into the master branch:

    git checkout master
    git pull                         => just to update master before merge
    git checkout feature/post_video
    git rebase master                => HERE CAME THE SECOND PROBLEM
    
  • From this rebase, I had sooooo many conflicts: for every single commit pushed in remote branch feature/post_video, I have to resolve a "conflict".

Can anyone tell me what I'm doing wrong in this workflow?

Thanks,

Aurelien
  • 277
  • 2
  • 9

3 Answers3

3

A checkout of a remote branch will left you in a DETACHED HEAD mode.

You should make your work in a local branch.

git checkout -b post_video feature/post_video

You can then make commits and even rebase them (as long as you didn't push your local commits) on top of an updated (fetched) feature/post_video (not on top of master, as it would change the history of the entire branch, not just your own commits on that branch)


You should have seen, on the ckeckout feature/post_video:

Note: checking out 'feature/post_video'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • When I checkout a remote branch, I see: Branch post_video set up to track remote branch post_video from origin. Switched to a new branch 'post_video'. – Aurelien Jun 23 '14 at 13:45
  • @Aurelien that looks good: you can start working on `post_video` – VonC Jun 23 '14 at 13:45
  • Yes, that looks good but it is not because now when my work on that branch is finished, I want to rebase master but there comes the second problem I described in my post. – Aurelien Jun 23 '14 at 13:58
  • 1
    @Aurelien then don't rebase on `master`, as I mentioned in the answer: you can merge `master` to your branch to update it with latest `master` commits while your branch isn't finished. – VonC Jun 23 '14 at 14:03
  • Ok so I did a `git merge master` from my `post_video` branch and it seems to be working. But still, I don't understand why the `git rebase master` did not worked... Thanks for your help! – Aurelien Jun 23 '14 at 14:19
0

I'm not sure what went wrong in the first case, but the biggest problem is likely that you're rebasing shared commits. This is virtually always a recipe for disaster.

When you rebase commits you change their commit hashes. The commits that you have and the commits that your friend has, even though they "do the same thing", are no longer the same commits. After that happens, your branches have effectively diverged. Git can't resolve the history in the way you want.

ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257
  • Ok. So how do you work with remote shared branches with multiple developers? – Aurelien Jun 23 '14 at 13:46
  • @Aurelien, I'm not sure what you mean. You can `rebase` local commits as much as you want, just don't do it with shared commits. There, `merge` instead. Just like you should be careful when pushing `master` to your shared repository you should also be careful when pushing other branches. If they need to be cleaned up, do that before pushing. – ChrisGPT was on strike Jun 23 '14 at 13:48
  • Ok, here is what I mean: you have 1 developer and I, one master, one remote branch called `post_video`. Developer no1 finished working on `post_video` and committed+pushed his changes. That's my turn now to work on `post_video`. I checkout `my_video`, write my code, commit and when I have finished, I want to `rebase master` and then to `checkout master` and `merge post_video` into master. But that final step is not working properly (see my second problem in my post). – Aurelien Jun 23 '14 at 14:34
  • @Aurelien, right, and I'm saying that rebasing shared commits is almost always a bad idea with Git. Instead of `git rebase master`, you should probably use `git merge master`. There are a lot of resources explaining why rebasing shared commits usually causes pretty big problems. – ChrisGPT was on strike Jun 23 '14 at 15:00
0

First problem: Check your git hooks. May be some of them are doing modifications during pull phase.

Second problem: Normally you create feature branch on the top of master. So when you want to merge you feature branch in master you have to do

git checkout master
git pull --rebase
git rebase feature/post_video
git push

And you will have it done.

teotanin
  • 1
  • 2
  • I prefer to rebase master inside my feature branch in order to avoid changing the master while my work in my feature branch is not finished. – Aurelien Jun 23 '14 at 13:47