If you're not already moderately familiar with Git, strongly consider browsing the [[#Git Structure]] section first as it can make Git operations easier to understand.

If you're not already moderately familiar with Git, strongly consider browsing the [[#Git Structure]] section first as it can make Git operations easier to understand.

+

+

If you're just looking for some handy commands, check out the [[#​Recipes]] section.

Line 153:

Line 155:

</​file>​

</​file>​

-

This sample output shows **six locally modified** files, ​none of which have any unstaged ​changes. Entering **''​2''​** enters the **update** mode, and then one or more files can be selected to be staged. Files can be specified in the following ways:

+

This sample output shows **six locally modified** files -- for example, ''​README.txt''​ has six lines added and four lines removed. None of the files have any **staged ​changes** however.

+

+

Entering **''​2''​** enters the **update** mode, and then one or more files can be selected to be staged. Files can be specified in at least the following ways:

^ ''​3''​ | Add a single file specified by number. |

^ ''​3''​ | Add a single file specified by number. |

Line 177:

Line 181:

What now>

What now>

</​file>​

</​file>​

+

+

Now we can see that changes have moved from the working directory into the index for those files that we've staged. If we made further modifications to the same files before committing then we'd see change summaries in both columns, since the staged files would differ from the current HEAD and the working directory copies would also differ from the staged ones.

The other options perform the following functions:

The other options perform the following functions:

Line 916:

Line 922:

Commands such as ''​git log''​ operate on a set of commits, not just a single one. To that end, the syntax for [[#single revisions]] is augmented in various ways to allow the specification of a range of commits:

Commands such as ''​git log''​ operate on a set of commits, not just a single one. To that end, the syntax for [[#single revisions]] is augmented in various ways to allow the specification of a range of commits:

+

+

<​note>​The syntax used by ''​git diff''​ appears superficially similar but is //not// the same!</​note>​

^ Method ^ Example ^ Explanation ^

^ Method ^ Example ^ Explanation ^

Line 1018:

Line 1026:

==== git diff ====

==== git diff ====

-

The ''​git diff''​ command is used to show differences between files in various locations. This is similar to ''​git log''​ in some ways, although ''​git diff''​ compares the differences in the endpoints rather than examining the full commit history. As a result, ​it doesn'​t accept ​the full set of [[#Revision Ranges|ranges]] ​that ''​git log'' ​does.

+

The ''​git diff''​ command is used to show differences between files in various locations. This is similar to ''​git log''​ in some ways, although ''​git diff''​ compares the differences in the endpoints rather than examining the full commit history. As a result, ​while the syntax appears superficially similar ​the [[#Revision Ranges|ranges]] ​used by ''​git log''​, the interpretations differ.

The possible invocations are:

The possible invocations are:

^ ''​%%git diff%%''​ | Show the differences between the current working directory and the index. |

^ ''​%%git diff%%''​ | Show the differences between the current working directory and the index. |

-

^ ''​%%git diff <​commit>​%%''​ | As ''​git diff'',​ but compare to the named commit instead of the index. |

+

^ ''​%%git diff <​commit>​%%''​ | As ''​git diff'',​ but compare ​the working directory ​to the named commit instead of the index\\ (e.g. ''​git diff HEAD''​ to compare to most recent commit on the current branch). |

-

^ ''​%%git diff --cached%%''​ | Show the differences between the index and the current HEAD.\\ Optionally, a different commit than than the HEAD can be specified. |

+

^ ''​%%git diff --cached ​[<​commit>​]%%''​ | Show the differences between the index and the current HEAD.\\ Optionally, a different commit than than the HEAD can be specified. |

^ ''​%%git diff <src-commit>​...<​dst-commit>​%%''​ | Show differences between the common ancestor of both commits and ''<​dst-commit>''​.\\ Omitting either commit causes Git to assume ''​HEAD''​. |

+

^ ''​%%git diff <from-commit>​...<​to-commit>​%%''​ | Show differences between the common ancestor of both commits and ''<​to-commit>''​.\\ Omitting either commit causes Git to assume ''​HEAD''​. |

As with ''​git log'',​ it's possible to supply one or more paths to filter the files diffed:

As with ''​git log'',​ it's possible to supply one or more paths to filter the files diffed:

Line 1148:

Line 1156:

Once this file is saved, Git proceeds with the rebase as normal. Conflicts are handled as per a [[#​Rebasing|standard rebase]] and the ''​edit''​ action will also require the use of ''​%%git rebase --continue%%''​ to carry on the rebase operation.

Once this file is saved, Git proceeds with the rebase as normal. Conflicts are handled as per a [[#​Rebasing|standard rebase]] and the ''​edit''​ action will also require the use of ''​%%git rebase --continue%%''​ to carry on the rebase operation.

+

+

+

==== Squash Merges ====

+

+

Similar in some ways to the ''​squash''​ option of interactive rebasing is the ''​%%--squash%%''​ option to ''​git merge''​. This allows multiple commits to be merged into a single commit on a different branch. The primary difference is that an interactive rebase modifies a source branch such that the destination could be fast-forwarded to it, whereas a squashing merge will create an entirely new commit on the destination branch which is the combination of all the source commits, leaving the individual commits intact on the source branch.

+

+

The syntax is the same as for a standard ''​git merge''​ with the addition of the ''​%%--squash%%''​ parameter. The result is that the index (only) is updated with the combination of all the source commits, so it differs from a standard merge in that this must then be committed to the repository with ''​git commit''​. In this way merges from multiple branches may be squashed together by repeated executions of ''​%%git merge --squash%%''​ prior to the ''​git commit''​. Any conflicts will be flagged and must be resolved as with a standard merge before continuing.

+

+

Once the commit is done, the history of each source branch is left untouched and a new commit will have been created on the destination branch which is the combination of the selected commits. The source and destination branches will have effectively diverged. The situation will be something like the following example, which assumes that other commits have been made to ''​master''​ before doing the merge.

As can be seen, the source branch is intact and could be left in existence as required, but unlike a rebase its commits haven'​t become part of the history of the destination branch so future merges may well produce conflicts. It's also worth noting that, unlike a standard merge, the final commit(s) on the branch(es) do //not// become parents of the mainline commit. The merged commit could have equally been created by manually applying the diffs of each source commit and an entirely new commit created.

===== Remote Repositories =====

===== Remote Repositories =====

Line 1272:

Line 1311:

The ''<​local branch>''​ here is typically a local branch name, but could be any commit specification (e.g. a SHA1 hash). The ''<​remote branch>''​ must be a real branch, however, to avoid creation of a **detached head**, but if a non-existent branch is specified then it will be created based on the source branch.

The ''<​local branch>''​ here is typically a local branch name, but could be any commit specification (e.g. a SHA1 hash). The ''<​remote branch>''​ must be a real branch, however, to avoid creation of a **detached head**, but if a non-existent branch is specified then it will be created based on the source branch.

+

+

<note important>​It'​s worth noting that this point that you should avoid modifying changes (for example, via an interactive rebase) once they'​ve been pushed or pulled to another repository unless you maintain both and are prepared to deal with the resultant conflicts.</​note>​

Normally the push operation fails if the remote merge operation is anything other than a **fast-forward** (i.e. the local repository has already merged all of the remote changes). If this is not the case, it will exit with an appropriate error and the remote changes will need to be merged locally first. If the branch specification is prefixed with ''​+'',​ the update will be done even if the merge is not a fast-forward.

Normally the push operation fails if the remote merge operation is anything other than a **fast-forward** (i.e. the local repository has already merged all of the remote changes). If this is not the case, it will exit with an appropriate error and the remote changes will need to be merged locally first. If the branch specification is prefixed with ''​+'',​ the update will be done even if the merge is not a fast-forward.