0

I'm not all that familiar with git, so bear with me. I have seen several references to 'git plush' as the "proper" method of pushing a committed change, and I have been using this for quite some time. However now, on a repo that I only started working on recently, plush is working differently than I have seen it work before. Now it is bring my tree up to date and then merging all the updated files into my commit and recommitting all of files that got updated with the pull.

# git commit
[master aaf2cc1] commit comment
1 files changed, 233 insertions(+), 0 deletions(-)
create mode 100755 my-file.rb
(19:23:11)-(rkasten@tash)-(jobs:0)-(! 633)-(~/project)
# git pull && git push
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 10 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (10/10), done.
From ssh://server.company.com/repo/git/project
   6a5aa62..228d9b1  master     -> origin/master
Merge made by recursive.
DEMO_files/joshtest.rb                             |  119 ++++++++++++++++++++
.../portal/prod-portal-config.json                 |    4 +-
portal-maintenance.rb                              |    5 +-
3 files changed, 124 insertions(+), 4 deletions(-)
create mode 100755 DEMO_files/joshtest.rb
Counting objects: 7, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 3.00 KiB, done.
Total 5 (delta 2), reused 0 (delta 0)
To ssh://snc@server.company.com/repo/git/project
   228d9b1..375bdf4  master -> master

As you can see, even though I committed only my 1 file (my-file.rb), my push results in a commit of my 1 file and a merge of those 3 files which were previously pushed by other people. So am I using git wrong? Like I said, I've never seen this problem before.

DrStrangepork
  • 2,955
  • 2
  • 27
  • 33

2 Answers2

1

When two branches diverges and you merge them, git need to create a merge commit.

For example:

master            /--* (Your commit)      ----* (merged commit)
origin/master  ------* (Colleague commit) --/

This is because the two commits are brancher from the same parent commit, so git will create an intermediate merge commit while merging these two branches.

To prevent this extra commits, you'll usually do it this way:

git checkout master # Your local branch
git fetch origin    # Fetch the head of origin/master
git rebase origin/master
# Fix any conflicts
git push

What this is doing is putting overwritting your branch so your commit appears as being written on top your colleage commit(s). The three after the rebase will looks like this

master --* (Colleague commit) --* (Your commit)
Simon Boudrias
  • 42,953
  • 16
  • 99
  • 134
  • `git rebase origin/master` does not work when I have unstaged changes that are not included in the commit. That doesn't work for me, as I often have unstaged changes. – DrStrangepork Nov 12 '13 at 22:02
  • I took me a few attempts to get this down right, but this does seem to be the correct approach. Splitting my edits into multiple commits, then doing a single push made life a lot easier. The concept of `'git pull && git push'` seems to imply "commit, push, commit, push, commit, push" rather than "commit, commit, commit, push" which I don't think will be the proper approach in most cases for the project I'm working on. – DrStrangepork Nov 14 '13 at 23:24
0

I recommend you just keep the operations separate.

I've worked in several shops and never seen that as a common practice (or at all).

In fact several places don't even like git pull, they prefer to keep the git fetch and git merge operations (that pull itself combines), separate.

I recommend looking into git workflow posts to guide you. Look for q/a's with a lot of upvotes.

This post may help: git branch, fork, fetch, merge, rebase and clone, what are the differences?

Community
  • 1
  • 1
Michael Durrant
  • 93,410
  • 97
  • 333
  • 497