HachiCode

Appearance

Committing changes ​

Open a project and switch to the Git mode. On an iPad, and on a phone in landscape, the modes sit on the rail at the left edge: Editor, Git, History. In portrait on a phone, the mode menu is on the toolbar.

The Git mode is where the next commit is put together. Fetching and pushing live in the History mode, where the existing commits are.

The Git view ​

The sidebar lists the working tree in two sections that are always there, Staged and Unstaged, with counts. New, modified, deleted, renamed and conflicted files all appear under Unstaged until staged. A third section, Shelved, appears when the shelf holds something. Tap a file to see its diff in the pane beside the list.

Each row carries one button for the move between the sections, Stage or Unstage, and a … menu for the rest:

  • Stage… and Unstage… open the hunk picker for a modified file, so you choose which changed blocks move.
  • Discard… throws away the unstaged changes to a file, after a confirm. For a modified file it opens the hunk picker, so you can discard some blocks and keep others.
  • Restore… brings back a deleted file from git.
  • Delete… removes an untracked file for good.
  • Shelve… moves the file's changes onto the shelf.

The section headers have their own menu: Stage all, Unstage all, Restore all, and Shelve… for the whole of Unstaged.

A conflicted file has no buttons. Staging a conflicted file is how git records it as resolved, so resolve it first, from the Integrate flow that produced it.

Picking hunks ​

The hunk picker shows the file's diff as blocks, each with a checkbox. All and None select in bulk; the arrows jump between blocks. The button at the foot says exactly what will happen: Stage 2 hunks, Unstage 1 hunk, Discard 3 changes. A binary change and a change of file mode appear as cards you can tick like any hunk.

A hunk is applied exactly as shown, never approximated. If the file changed on disk, or the index moved, since the picker opened, the apply refuses and you pick again from the fresh diff.

The commit screen ​

Tap the commit button on the sidebar toolbar. The screen shows the Last commit for reference, a Title field, an Optional commit message field, and under In this commit the files that are staged. The button is disabled until there is a title and something staged.

The usual conventions apply: a short imperative title, a blank line, then the reasons in the body.

Amend ​

Amend last commit rewrites the most recent commit instead of adding one. The staged files join what that commit already had. With nothing staged, the screen opens straight into amend with the old message prefilled, and the only thing left to change is the message: until you edit it, the button says so and waits. Turning the switch on with files staged leaves the message you typed alone; the old one shows in the tip row.

Amend is refused on a detached HEAD, and on a commit that is already pushed — amending it would rewrite shared history — and the screen says so; see Push and fetch.

Who the author is ​

Commits carry the identity from Settings → Git. A project can override it under Git in its settings, which is how a work account and a personal one coexist. The identity is written into the repository's own configuration, so a repository read by other tools sees the same author.

Read-only projects ​

A project marked read-only, and every git project on the free plan, shows "This project is read-only, so staging, commits, and branch changes are disabled." in place of the actions. The diffs and the history stay readable.

After the commit ​

The staged section empties and the commit appears at the top of the History mode, marked Not yet pushed until it reaches the remote. To send it, see Push and fetch.

See also ​

Last updated: