sharptooth
sharptooth

Reputation: 170509

What's the right way to push changes when they clash with changes from other users in Git?

I'm trying to get familiar with Git having only SVN prior experience. I have created an empty local repository and pulled a remote repository there. Then I make a change in my local repository and commit it. Meanwhile another user makes and pushes an unrelated change to the same remote repository.

I try to push my changes using git push and see a message that I have to merge before I push. So I do git pull and then git push.

The log at hithub.com now displays two entries. The first one has the very same description as what I entered when committing locally and the very same changes that I committed locally. The second one has description

Merge branch 'master' of [URL of the remote repo]

and the changes that the other user made.

Ideally I'd like it to look as with SVN workflow - that I'd "update" to the latest revision merging all the changes made by the other user and then commit and push my changes.

Why does Git exhibit this behavior and how do I achieve the right behavior?

Upvotes: 0

Views: 462

Answers (1)

Mark Longair
Mark Longair

Reputation: 467741

The merge commit that you describe represents the state of your project after merging your changes and the other user's changes:

 [last common commit]----[other developer's commit]----[merge commit]
                     \                                /
                      \                              /
                        -------[your commit]--------

If you don't like having that non-linear structure, then you can pull with git pull --rebase, which will try to reapply the changes introduced by your commits on top of your colleague's, leaving history like this:

 [last common commit]---[other developer's commit]----[your commit]

Personally, I don't mind having the merge commits in the history, but opinions vary...

Upvotes: 3

Related Questions