Merging

Merging brings the commits from another branch into the one you are on. What a merge is explains what that does to the history. Innesta does three kinds, and which is right is a question about the history you want, not about which is safer.

Regular merge

A merge commit, joining the two lines of development. Innesta passes --no-ff, so there is one even where the branch could have been fast-forwarded, and the graph shows what actually happened: work proceeded in parallel and then came together.

Selecting the merge commit in the history shows what it brought in.

Squash merge

The other branch’s changes arrive as one commit on this branch, and its own commits do not appear in this history at all.

Useful when a branch’s history is a record of how you got there — twelve commits of “wip”, “fix”, “actually fix” — and only the result is worth keeping.

Rebase

Not a merge at all, but the third answer to the same question. See rebasing.

The default

The Use Default action in the branch menu applies whichever strategy you have set in App Settings, so a repository with a house style does not need the decision made again every time.

Signing

A merge you start from Innesta uses the Sign commit toggle as it stands. Continue, after resolving a conflict, uses it as it stands then too. See committing.

If it conflicts

Git stops and marks the files it could not settle. Innesta marks them in the working copy, and the three-pane editor is where you resolve them. Nothing is lost while a merge is in progress and it can be abandoned.