2

I have an issue. I have 2 branches, which are master and my-destinations. I made some changes on my-destinations branch that are not on master. I committed and pushed the changes onto my git repo from the my-destinations branch.

When I switch back to master the changes I committed and pushed onto the repo are not there, which I expected. However, when I switch back to master and run a git status it says that master is up to date. I would have thought that it would have said that master is one commit behind origin.

Can someone help me understand why master is up to date with origin/master, but does not have the committed changes?

msanford
  • 11,803
  • 11
  • 66
  • 93
meddy
  • 385
  • 6
  • 21

2 Answers2

1

Can someone help me understand why master is up to date with origin/master, but does not have the committed changes?

Your local master branch has the same files than github remote master branch. That is why your (local) master branch is not behind your (remote) master branch.

Your (local) master branch would be behind (any amount of commits) if someone else (or you from any other remote computer) had commited new changes into the (remote) master branch.

lilezek
  • 6,976
  • 1
  • 27
  • 45
1

You added commits to my-destinations, in your local repo, not to master:

a              <-- master ref is (a)
 \
  b - c - d    <-- my-destinations ref is (d)

When you pushed to origin, the remote repo, it simply took your existing local master branch, and made the remote repo master to be the same. In other words, the remote master was updated to reference (a), just like your local master. If it was already at (a), there would have been no change at all made to the remote.

Your remote is named origin, which is the standard naming convention. So, if you add a local tracking branch for the remote master, it will be called origin/master, and it will reference the same commit after a push occurs for that branch:

a            <-- master (a)*  <-- origin/master (a)
 \
  b - c - d  <-- my-destinations (d)

(*) - Indicates branch that is checked out

Note that if you did not push while my-destinations was checked out, then origin wouldn't have your new commits b, c, and d, unless you used command-line flags or some other method to push all the branches to origin. If you did push with my-destinations checked out, then there would also be b-c-d commits on the remote and an origin/my-destinations local tracking reference that would also point to (d).

But the big question is how to get your new commits back to master. To get your new commits to master from my-destinations, you can just git merge my-destinations with master checked out, which, in this case, will just "fast-forward" master up to the (d) commit, since master is referencing a parent of my-destinations (i.e. they didn't diverge - you can think of a-b-c-d as a straight line rather than a branch). After the merge, you would have:

a            <-- origin/master (a)
 \
  b - c - d   <-- master (d)*  <-- my-destinations (d)

Then, after pushing to remote, origin/master will update so that it matches master at commit (d) - i.e. all three refs would be pointing to (d).

Note: If master and my-destinations had diverged, you could either merge or rebase to bring them back together. Look up "visual git tutorial" in Google and you should run across several good tutorials that will walk you through these.

Also note: I recommend Git Extensions as an open-source GUI tool that will help you see exactly what is going on with your branches, commits, local and remote much more easily with a GUI. It has helped me learn Git a lot easier, I always have it open in the background while working in Visual Studio or other tools in the foreground. It will basically show you something similar to the diagrams above for whatever repo you have open, as changes are made.

LightCC
  • 9,804
  • 5
  • 52
  • 92