Git merge

[sKunKbad]

I use git every day, but don't do much with branches because I work alone. I'm curious about something related to the branches, when a new branch is on a remote, and then it needs to be fetched and merged separately from the master branch.

 

So pretend I'm on the master branch on my machine:

git checkout -b develop
# I make changes to files on develop
git add .
git commit -am "I have made changes to develop"
git push origin develop

Now there is a develop branch on the remote. Somebody else now fetches and merges (they are on master):

git fetch origin
# git shows that there is a new branch develop, and merge is also required for origin/master

Normally without the develop branch, I would run this command from master:

git merge origin/master

Do I also need to checkout develop and merge origin/develop?

# Do I need to do this too?
git checkout develop
git merge origin/develop

Is there a way to merge all branches with their remote counterparts, all in one command?

 

[requinix]

Normally you work on one branch at a time. If you want your master to be up-to-date then you would do a fetch/merge (or a pull which is the same thing). Actually, for something like master, you should never be committing to it anything besides merges from other branches so I do a fast-forward merge.

Normally you would then, later, decide you want to work on the develop branch. You check it out, do a merge, resolve conflicts, and begin working.

 

No, you cannot merge into multiple branches at once with a single command. The main reason would be the difficulty with conflict resolution.

 

What you can do is script it yourself: fetch, for each branch { checkout, merge, do something in case of conflicts (eg, pause and wait for the user to resolve), and commit }

[sKunKbad]

Normally you work on one branch at a time. If you want your master to be up-to-date then you would do a fetch/merge (or a pull which is the same thing). Actually, for something like master, you should never be committing to it anything besides merges from other branches so I do a fast-forward merge.

Normally you would then, later, decide you want to work on the develop branch. You check it out, do a merge, resolve conflicts, and begin working.

 

No, you cannot merge into multiple branches at once with a single command. The main reason would be the difficulty with conflict resolution.

 

What you can do is script it yourself: fetch, for each branch { checkout, merge, do something in case of conflicts (eg, pause and wait for the user to resolve), and commit }

 

Interesting. I thought it would be normal to have a bunch of different branches, so that different things could be worked on separately from other things. For my own purposes,  a single branch is fine.

 

One thing that seems strange to me is that I am noticing that commits on develop that are not merged with master seem to be automatically merged with the local develop branch when I fetch/merge the master branch. For instance, right now develop is ahead of master by one commit, and when I fetched/merged local master with origin master, local develop was magically merged. So, it would seem that fetch/merge on master automatically brings all of the other branches up to date.

[requinix]

Interesting. I thought it would be normal to have a bunch of different branches, so that different things could be worked on separately from other things. For my own purposes,  a single branch is fine.

No no, you can have multiple branches. You're supposed to. Mind you, if it's just you working then there's a good chance you'll just work on one branch until you're done, merge, and then start a new branch. Or maybe you have one, decide you want to do something else for a while, and start another one. But multiple branches is definitely a thing.

 

I meant you can only have one checked out at a time. In the working directory. If you want to work on a second branch then you either (a) commit/stash your current stuff and switch branches or (b) clone a whole new second repository and do the second branch on that. The former is the normal way of doing it, and while the latter isn't necessarily wrong it can make things confusing (like "which clone was I doing $branch with?").

 

One thing that seems strange to me is that I am noticing that commits on develop that are not merged with master seem to be automatically merged with the local develop branch when I fetch/merge the master branch. For instance, right now develop is ahead of master by one commit, and when I fetched/merged local master with origin master, local develop was magically merged. So, it would seem that fetch/merge on master automatically brings all of the other branches up to date.

...No? I don't know what you're seeing but when you do a merge/pull you're only updating the branch you have checked out. Fetch can update all remote branches but any local branch remains where it was.

[sKunKbad]

...No? I don't know what you're seeing but when you do a merge/pull you're only updating the branch you have checked out. Fetch can update all remote branches but any local branch remains where it was.

 

Well, maybe our versions are different or something. Fetch followed by merge seems to be updating my local develop, even when I'm on the master branch. My git version is 2.7.0, and I'm on Ubuntu 14.04.

[requinix]

Did you make any commits to develop once you forked from master?

[sKunKbad]

Did you make any commits to develop once you forked from master?

 

Yes, and they were not merged with master.

[requinix]

Can you post a commit graph? Looks like one of the things shown here. Here's one from GitHub:

 

[edit] The black line is master. Didn't need to redact that.

Edited January 20, 2016 by requinix

[requinix]

Okay, just did a test.

 

0. Made a repo on GitHub

 

First directory:

1. Cloned repo, on "master"

2. Added and committed file #1

3. Branched to "branch"

4. Added and committed file #2

5. Pushed both branches, still on "branch"

 

master and origin/master have file #1, branch and origin/branch have files #1 #2.

 

Second directory,

6. Cloned repo, on "master"

7. Added and committed file #3

8. Pushed master

 

Second directory's master and origin/master have files #1 #3, branch and origin/branch have files #1 #2.

 

First directory,

9. Fetched (updated origin/master, local master still has #1)

10. Merged origin/master into master (got file #3)

 

The branch is still where it was: files #1 and #2.

[sKunKbad]

I've been using branches a lot more since I created this thread, and I think this scenario is explained as follows:

 

When a local repo is fetching from origin, if origin has a repo that local has not yet had, when checking out that new branch for the first time, the branch is automatically current with origin/"branch".

[requinix]

...Yes? It wouldn't be very nice if you checked out a local copy of a remote branch and it wasn't up to date.