10

I am working on the same branch as my colleagues. Now I have committed some files and sent for code review and so has some other co-worker. Now he pushes his code before I do. I now need to pull his changes back and then add my changes. But it's already committed.

How do I get his changes and then add my changes without the history looking bad and me having to jump hoops? I am very new to git.

javabrett
  • 7,020
  • 4
  • 51
  • 73
user2759617
  • 597
  • 1
  • 8
  • 20
  • You might find this helpful: http://stackoverflow.com/questions/18930527/difference-between-git-pull-and-git-pull-rebase – jcm May 22 '15 at 07:06
  • 1
    Please provide any explanation about the exact flow you've made. The answer realy realy depends on it. "*Now I have committed some files and sent for code review*" => Do you mean you pushed ? If yes, what branch ? "*Now he pushes his code before I do*" => what branch ? – Cyril CHAPON May 22 '15 at 08:42

3 Answers3

16

You can use git pull --rebase. This will fetch your collegues commits and then put your commits (that you haven't pushed) on top of them, keeping the history looking good as well.

Edit: Cyril CHAPON made some good points in his comment. Take a look at some of his links to fully understand the how rebase works and to avoid pitfalls.

crea1
  • 11,077
  • 3
  • 36
  • 46
  • 2
    Any advise including a `rebase` should include a warning about the [golden rule](https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing/). Plus, even if that answer is that closest one, it dramatically deserves some explanations, at least a [useful link](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) – Cyril CHAPON May 22 '15 at 08:06
2

As already stated you can do a git pull --rebase but there is also a different approach you go with: Imagine your history now look like this:

A -> B -> C -> D | | local master remote/master You can do the following:

$ git branch save_state $ git reset --hard C Basically this brings you to

A -> B -> C (remote/master) \ -> D (local save_state)

You know pull the changes from remote into your master

$ git pull origin master

Which will lead to a fast forward merge(history is clean up to here) And know you can do a

$ git checkout save_state $ git rebase master $ git checkout master && git merge save_state You can rebase this branch here without problems because it doesnt have been pushed to remote yet.

ckruczek
  • 2,361
  • 2
  • 20
  • 23
  • Exactly same remark as [my previous comment](http://stackoverflow.com/questions/30390337/working-on-the-same-branch-how-to-pull-without-losing-changes/30390416#comment48871182_30390416). He stated that he **already pushed** for code review, including any possible other commits by his community **after** his work. Rebasing should be realy realy warned. – Cyril CHAPON May 22 '15 at 08:36
  • He just stated he commited and send for review. Does'nt implicitly mean he already pushed I would guess. – ckruczek May 22 '15 at 08:37
  • You're right. "*Sent*" isn't obvious and the following explanation about "*Now he pushes his code before I do*" should include any branch name or whatever. – Cyril CHAPON May 22 '15 at 08:39
  • Yup, we should wait for any reaction of the QO,and if he really pushed already, I will definitly edit my answer. Because you are absolutly right then. Rebasing after pushin isn't a good idea though :D – ckruczek May 22 '15 at 08:41
0
git pull

That will get his changes from the remote server, bring them locally to your machine, and then merge his work in with yours. This will give a join in the history: one branch with your work, one with his, and then a join when the two are brought together. Git will give you the opportunity to fix any conflicts if that is necessary, but it does a great job of merging automatically.

I very strongly recommend that you read this: https://git-scm.com/book/en/v2

Ewan Mellor
  • 6,747
  • 1
  • 24
  • 39