Does GIT merges based on datetime?

I would like to understand how GIT merge happens.

Master & Feature

A--B--C --G--H--I

       --D--E--F

Here is the changes made and date when it was changed.

G(Master) – Aug – 8th
H(Master) – Aug – 10th
I(Master) – Aug – 15th

D(Feature) – Aug – 9th
E(Feature) – Aug – 11th
F(Feature) – Aug – 12th

So, now If I merge master branch into feature how does the history appear? Does it merge based on the date change and display like this?

Feature branch

A--B--C--G--D--H--E--F

  • Reading GIT Merge Markers
  • Why git gives priority to a cherry-pick commit over the revert commit?
  • Git: Merge old commit into current head version
  • A little git trouble
  • How to merge two branches without a common ancestor?
  • Git: merging public and private branches while while keeping certain files intact in both branches
  • How do I merge locally a master and a fork in git?
  • Git won't let me merge
  • 3 Solutions collect form web for “Does GIT merges based on datetime?”

    The way git does a merge is that it creates if you will, a patch of the diff between your current branch and the branch you are trying to merge. It then simply applies that patch as a whole to your branch with the commit –

    Merge "Source Branch" into "Target Branch"
    

    This is basically the only new commit that you are having. If you want to revert --D--E--F then you don’t revert them individually, but revert this big merge commit.

    As for the time stamp, yes git will now also give you a merge of the commits themselves in both the branches that you can revert by yourself.

    So imagine it something like this,

    Branch 1: A - B - C -           - G - H - I
    Branch 2:             D - E - F
    

    Merging these together in Branch 1 will give you –

    Branch 1: A - B - C - D - E - F - G - H - I - J (Here, J = D + E + F)
    

    On the other hand, a rebase would give you :

    Branch 1: A - B - C - G - H - I - J - D* - E* - F* (Here, D* = D's changes)
    

    If you are on branch master, and execute git merge feature, your history will be changed from this :

    A--B--C---G--H--I (master)
           \
            \-D--E--F (feature)
    

    to this :

    A--B--C---G--H--I---J (master)
           \           /
            \-D--E--F-/ (feature)
    

    git will compare the two diffs C vs I and C vs F, and try to build a new commit which combines the changes in these two diffs.
    git mays ask you to manually solve conflicts if some changes on I overlap some changes in F.

    git will not modify any of the existing commits, so that, on a shared repo, the other developpers’ copy of the repo is not messed up.

    git merge does not take into account the date of the commit(s) ; it just looks at the succession of commits (the fact that G comes after C in the graph, for example).


    There is another command, git rebase, which will change the structure of the existing commits, and may force other developpers to do extra work if they want to keep their local copy in sync with the remote server.

    git rebase is a useful command, but it is generally advised to use it only locally, before you share some modification (e.g. : only use it on modifications which have not yet been git pushed).

    If you merge master branch to feature, it will make a new commit with its log like “Merge branch master to into feature”.

    you won’t get history like A-B-C-G-D-H-E-F

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