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, and pushing it publishes it: the sheet is headed Publish Branch, and proposes a branch of the same name on the remote you push to — see the end of this page. Confirming pushes it there and makes that the upstream, and from then on the pull and push buttons can count how far behind or ahead you are. Force pushing is not offered while a branch is being published.

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.

A branch that tracks a remote branch with another name is published as well, rather than pushed into the branch it tracks: Publish Branch proposes one under the local branch’s own name, says which upstream that replaces, and replaces it only once the publish has worked.

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. A tag is pushed as you make it, or on its own afterwards, 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.