Merging

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

Regular merge

Both lines of development are kept, joined by a merge commit with two parents. Innesta passes --no-ff, so there is a merge commit 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

Every commit from the other branch is flattened into one commit on this branch. The other branch’s individual 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.