Pushing

Pushing sends the commits on your branch to the remote. Innesta shows a preview of the files involved first, in the Diff Review window.

A preview before a push is less about safety than about noticing. Pushing is not destructive, but “what did I just send?” is a question best answered before sending, particularly on a branch you have been rebasing or amending.

The first push of a branch

A branch that has never been pushed has no upstream. Pushing it establishes one, and from then on the pull and push buttons can count how far behind or ahead you are.

Pushing is not the only way to get one. If the branch should be measured against a remote branch that already exists — under another name, or on another remote — choose it from Upstream Branch in the branch’s context menu; see the upstream branch.

Rejected pushes

The remote rejects a push when it has commits you do not have. That is not an error to work around; it means someone else pushed since you last looked.

Innesta offers the way out rather than leaving you to work it out: a dialogue headed Remote Changes Need Update, with Update & Push, which integrates the remote’s commits and then pushes yours if that completed cleanly. It shows the same preview a pull would.

What you must not do reflexively is force: see force push with lease for when it is right and what Innesta does about it.

Tags

Tags do not travel with commits. They are pushed selectively, so a local tag stays local until you choose to send it.

Where it goes

The push destination is Git’s, not Innesta’s: branch.<name>.pushRemote, then remote.pushDefault, then the branch’s own remote, then origin, then the only remote if there is only one. Innesta resolves it the way Git does so that a repository configured for a particular workflow behaves the same here as on the command line.