0

We're in the process of switching from SVN to git, and I've noticed that we're seeing a lot of these commit messages in git:

Merge branch 'development' of [Url to Origin].

These are coming in where other developers are pulling down changes from remote, into their local repo, before they push their changes back into remote (I think, clarification would be great if not).

I just wanted to check that it's expected to see these messages in the remote, considering there's only 3 of us working on the project at the moment, but it seems like every other commit is one of these messages, making it a bit harder to gleam any useful information from the commit logs?

(Tagged as Visual Studio as I believe the message is auto-generated by VS when you use their IDE?)

Psytronic
  • 233
  • 1
  • 6
  • 1
    possible duplicate of [Git commit messages with nvie branching model](http://programmers.stackexchange.com/questions/166486/git-commit-messages-with-nvie-branching-model) – Bart van Ingen Schenau Nov 24 '14 at 10:57
  • There is nothing language specific about your question. It would do the same thing if it were simply a text file with many contributors, or a complex project with many languages. The message is in fact generated by git. – vgoff Jan 03 '15 at 23:42

3 Answers3

3

These are coming in where other developers are pulling down changes from remote, into their local repo, before they push their changes back into remote (I think, clarification would be great if not).

That's absolutely correct.

I just wanted to check that it's expected to see these messages in the remote,

It's perfectly normal. If they're very noisy, alternatives are:

  1. use git pull --rebase (you can configure this as the default behaviour) instead. This means everyone's local changes are always (re)based onto the remote branch HEAD, and pushes are always fast-forward.

    You do have to be comfortable with fixing the rebase if it doesn't apply cleanly though, and with commits showing up out of time order

  2. work on feature branches and merge less frequently

Useless
  • 12,380
  • 2
  • 34
  • 46
  • 1
    But when you do get comfortable with fixing rebase conflicts, it can be a lot easier than a merge, as you have to fix one commit at a time (which hopefully has a helpful commit message) instead of fixing all merge conflicts in one go. – Pete Nov 24 '14 at 15:30
1

Since git is (in my opinion, and maybe everyone else's) more complicated than SVN, answering this single question will do you more harm than good. Sounds like you didn't spend time on learning the fundamentals.

I suggest you (and your entire team) read the great, well written tutorials by Atlassian (go to the 'getting started' section). I read them after some time of just winging it with git after migrating from svn, and I can't stress enough how important it is to actually sit down and read about how things work there:

https://www.atlassian.com/git/tutorials/

Erez Eshkol
  • 331
  • 1
  • 5
0

Having the merge commits and seeing the merge commits are really different things.

If you only are concerned with reporting, you can use arguments to the git log command.

Having two parents is why they exist.

The workflow is 'correct' in that it is not technically a problem. But your workflow may change as you become more familiar with the git toolset. And then you may change your workflow to something more 'correct' for you.

vgoff
  • 227
  • 3
  • 11