Using git, why don't commits appear in the history after merging into a feature branch?

I have 2 branches, the main branch and a feature branch. Both branches had ongoing changes. I merged changes from the main branch into the feature branch. There were a few conflicts, which I resolved. I then staged the updated files.

In the merge, there were a number of other commits that didn’t have any conflicting files.

  • How do I make commit diff appear in commit message while I'm editing it (with Vim)?
  • Git:Why after Re-basing still my fork is behind the original repo master?
  • escape double quotes in git config from cmd
  • Git: how do I find tags pointing to specific revision?
  • Rollback to previous commits to find when bug was introduced
  • Branch is behind master
  • With that, there are 2 things I don’t understand.

    1. For the commits that didn’t have any conflicts, shouldn’t they show up in the history of the feature branch? Following the merge, there is nothing in the feature branch history for any of the work that was done on the main branch.
    2. Pertaining again to the commits that didn’t have any conflicts, why do those files show up as being changed when running git status on the feature branch?

    Admittedly, there is probably something fundamentally missing in my understanding of what should happen…

  • Travis does not have permission to pull git(hub) submodule
  • What should be in a first commit?
  • Why do people put the .env into gitignore?
  • How do you stay up-to-date in your feature branch (Git)?
  • git merge local with remote master using terminal
  • Move Git folder containing submodules
  • 2 Solutions collect form web for “Using git, why don't commits appear in the history after merging into a feature branch?”

    For the commits that didn’t have any conflicts, shouldn’t they show up in the history of the feature branch? Following the merge, there is nothing in the feature branch history for any of the work that was done on the main branch.

    In your question, you talk about merge conflicts happening on commits.

    In the merge, there were a number of other commits that didn’t have any conflicting files.

    Git doesn’t merge commits, it merges content. This indicates to me you have a misconception about how Git works (which Git doesn’t do much to dispel, so no worries). Let’s sketch what your repository looks like before a merge…

    A - B - C - D - E - F [master]
             \
              1 - 2 - 3 [feature]
    

    You have a master branch with commits A, B, C … F. Then you have a feature branch off of C with commits 1, 2 and 3. You can see this with git log --graph --decorate --all or you can use a graphical tool such as gitk or GitX-dev

    You want to merge the changes from master into feature. Git merges by taking the content of master and feature and creating a new commit which combines the two.

    A - B - C - D - E - F [master]
             \           \
              1 - 2 - 3 - F3 [feature]
    

    How it does that merge is another question. The important thing to realize is Git is merging the content of F and the content of 3.

    You can see from the graph, feature and master aren’t woven together. feature’s history remains distinct from master’s history. Branches do not go away when you merge. If you continue to commit to feature and master, they will diverge again.

    A - B - C - D - E - F - G - H [master]
             \           \
              1 - 2 - 3 - F3 - 4 - 5 [feature]
    

    This is why it may not appear that master’s history is showing up in feature’s, but it is now that F3 has both F and 3 as its parents.

    Pertaining again to the commits that didn’t have any conflicts, why do those files show up as being changed when running git status on the feature branch?

    As mentioned above, when Git does a merge it’s creating a new commit with the combined changes in the two branches. This is a normal commit like any other except it has more than one parent. If there is a conflict, Git needs a human to resolve it. You’re left with Git’s unfinished work. Any files which Git was able to merge successfully will be changed and staged (added). Anything which had a conflict will be changed (with conflict markers) and left unstaged. It’s up to you to edit the conflicted files, add them and commit. Same process as normal.

    I think the fundamental notion about Git that’s missing is this:

    In Git each commit represents a snapshot of your entire directory tree at a certain point in time.

    When you issue commands like git show <commitref>, Git is comparing the current state of your working tree with the state your working tree was at the point in time when that commit was made and showing you the net differences.

    Now, when you merge two branches, say A and B, you’re actually merging the snapshots of your directory tree as they were at the time when the latest commits were made in branch A and branch B, in this example C3 and C5.

    C1 - C2 - C3 <-- A
          \       
           C4 - C5 <-- B
    

    The resulting merge commit represents the sum of the two snapshots of your directory tree referenced by C3 and C5. In other words, the snapshot in C5 is put on top of C3, producing a new snapshot called C5', or “C5 prime“. That merge snapshot is special in that it has two parents instead of just one.

    C1 - C2 - C3 - C5' <-- A
          \       /
           C4 - C5 <-- B
    

    If both snapshots contain different versions of the same lines in the same files a conflict emerges. In that case, you have to decide how those lines are going to look like in the merged snapshot.

    Remember, since each commit is a snapshot representing the cumulative transformations that your directory tree has gone through before it, a merge commit is just a new snapshot, not a sequence of snapshots.

    That’s why you don’t see a list of commits from your main branch into your feature branch. Instead, you get a merge commit that represents the sum of the transformations that have happened to your files in the two branches. In order to allow you to track backwards through those earlier transformations, a merge commit contains a reference to the latest commits that were summed together.

    Git Baby is a git and github fan, let's start git clone.