Difference between revisions of "Git/merge"

from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
< Git
Jump to navigation Jump to search
(process)
(I think I understand more about how this works now, so clarifying my explanation.)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
'''Action''':  join two or more development histories together
+
==About==
 +
'''Action''':  join two or more {{l/same|branch}}es together
  
"Incorporates changes from the named {{l/same|commit}}s (since the time their histories diverged from the current {{l/same|branch}}) into the current branch. This command is used by [[../pull|git pull]] to incorporate changes from another repository and can be used by hand to merge changes from one branch into another."
+
In its simplest form, '''git merge''' lets you assimilate {changes that were {{l/same|commit}}ted to another branch} into the current branch:
 +
 
 +
* <code>git checkout {{arg|current-branch}}</code> - just to be sure we're starting with no uncommitted changes (a "clean" state)
 +
* <code>git merge {{arg|other-branch}}</code> - assimilate changes from {{arg|other-branch}} into this one
 +
 
 +
This is also done (or attempted) automatically when {{l/same|pull}} is used.
  
 
Things to remember:
 
Things to remember:
Line 7: Line 13:
 
* If the merge fails, you can "back out" with <code>git merge --abort</code>.
 
* If the merge fails, you can "back out" with <code>git merge --abort</code>.
 
* If things get too ugly and you just want to revert to a known state, <code>git {{l/same|reset}} --hard {{arg|commit}}</code> blows away all uncommitted changes and reverts to the given commit.
 
* If things get too ugly and you just want to revert to a known state, <code>git {{l/same|reset}} --hard {{arg|commit}}</code> blows away all uncommitted changes and reverts to the given commit.
 +
** Note: I think "commit" might refer to a specific hash value, not a branch name.
 
==Process==
 
==Process==
''This is incomplete; documentation will be ongoing as I figure out how this works.''
+
If a merge attempt is not successful, the local file will be marked up with notes indicating the differences between versions. The markup format seems to be:
 +
: <<<<<<< HEAD
 +
: ''text of local version''
 +
: =======
 +
: ''text of remote version''
 +
: >>>>>>> ''long hexadecimal identifier''
  
When you do a [[git pull]] in which there are conflicts between the remote and local versions, the following will happen:
+
(Tentatively:) If you attempt a commit while any of these markers are still in place, Git will refuse to commit and will list the files with unresolved differences.
* Git will attempt to "auto-merge" each conflicting file.
+
===Auto-Merge===
* For each file, there will be a message saying whether the merge was successful.
+
During a <code>{{l/same|pull}}</code>:
* If the merge is not successful, '''the local file will be marked up''' with notes indicating the differences between versions. The markup format seems to be:
+
* Git will attempt to "auto-merge" each conflicting file (i.e. merge from the remote branch into the current one).
*: <<<<<<< HEAD
+
* For each file, there will be a message saying whether the merge was successful (as above).
*: ''text of local version''
 
*: =======
 
*: ''text of remote version''
 
*: >>>>>>> ''long hexadecimal identifier''
 
* What's not clear yet is what to do after resolving the conflicts, or how to indicate that they are resolved. Possibly it should be:
 
** Save all files the way you want them to be.
 
** [[git add]] the changes back into the staging area.
 
** [[git commit]] the changes.
 
** [[git push]] the committed changes back to the remote.
 
 
==Outlinks==
 
==Outlinks==
 
===Documentation===
 
===Documentation===
 
* [https://www.kernel.org/pub/software/scm/git/docs/git-merge.html manpage @ kernel.org]
 
* [https://www.kernel.org/pub/software/scm/git/docs/git-merge.html manpage @ kernel.org]
 
===How To===
 
===How To===
 +
* [http://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging 3.2 Git Branching - Basic Branching and Merging]
 
* [http://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging 7.8 Git Tools - Advanced Merging]
 
* [http://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging 7.8 Git Tools - Advanced Merging]

Latest revision as of 10:44, 19 July 2018

About

Action: join two or more branches together

In its simplest form, git merge lets you assimilate {changes that were committed to another branch} into the current branch:

  • git checkout <current-branch> - just to be sure we're starting with no uncommitted changes (a "clean" state)
  • git merge <other-branch> - assimilate changes from <other-branch> into this one

This is also done (or attempted) automatically when pull is used.

Things to remember:

  • It's better to have all changes committed before you try a merge.
  • If the merge fails, you can "back out" with git merge --abort.
  • If things get too ugly and you just want to revert to a known state, git reset --hard <commit> blows away all uncommitted changes and reverts to the given commit.
    • Note: I think "commit" might refer to a specific hash value, not a branch name.

Process

If a merge attempt is not successful, the local file will be marked up with notes indicating the differences between versions. The markup format seems to be:

<<<<<<< HEAD
text of local version
=======
text of remote version
>>>>>>> long hexadecimal identifier

(Tentatively:) If you attempt a commit while any of these markers are still in place, Git will refuse to commit and will list the files with unresolved differences.

Auto-Merge

During a pull:

  • Git will attempt to "auto-merge" each conflicting file (i.e. merge from the remote branch into the current one).
  • For each file, there will be a message saying whether the merge was successful (as above).

Outlinks

Documentation

How To