Committing changes

Inside a project workspace, the activity bar on the left side has modes: Editor, Git, and Git History among others. Switch to Git to see your working-tree changes and create commits.

The commit identity

Every commit needs an author. The first time you create a project, hachicode prompts you for a name and email — that becomes your global commit identity, used by default for every project.

You can change the global identity in Settings → Git, or override it per-project in Project settings → Git. Per-project overrides are useful when you push to multiple hosts with different identities (a work GitHub account and a personal one, for instance).

The Git mode view

The Git mode shows:

• A list of changed files in the working tree, grouped by status (modified, added, deleted, renamed, untracked).
• A diff view for whichever file you've selected — the same inline format git's standard tools produce, with old / new line numbers and color-coded additions and deletions.
• A commit message input at the top, with the Commit button to its right.

Switch back to Editor mode any time to keep editing; your working-tree changes persist between mode switches.

Staging model — there isn't one

Hachicode commits all working-tree changes at once. There's no git add step, no index, no "staged" vs "unstaged" distinction.

If you want to commit a subset of changes:

• Discard the changes you don't want to include, commit, then redo them. The Git mode has a per-file discard affordance.
• Or commit everything and split it later on a laptop where the full index workflow is available.

The simplification is deliberate: at iPad scale the index step adds friction without proportional value. Most edits in hachicode are focused enough that "commit everything I've touched" is the right granularity.

Writing a commit message

Type into the message input above the file list. The standard git conventions apply:

• First line is the subject: present-tense, imperative, under ~70 characters ("Fix the off-by-one in pagination," not "Fixed pagination bug").
• Blank line, then optional body paragraphs explaining the why.

The commit button stays disabled until you've typed something and there's at least one changed file to commit.

Amend the previous commit

The commit input area has an Amend toggle. With it on, your commit re-writes the most recent commit instead of creating a new one. The new commit takes:

• The new commit message you typed (or the old message, pre-populated, if you don't change it)
• The current working-tree changes added on top of the previous commit's changes

When not to amend

Don't amend a commit you've already pushed to a remote others use — it rewrites history and the next push will be rejected or, worse, require a force-push that disrupts other readers. Amend only unpushed commits.

Deleted and renamed files

• Deleted files appear in the change list marked Deleted. They commit as D entries (git's "deletion" — the file is removed from the next snapshot).
• Renamed files appear marked Renamed when git detects them as a rename (which it does by content similarity). Otherwise a rename shows as a deletion + addition.

Both commit automatically as part of "everything in the working tree."

After the commit

Once the commit succeeds:

• The change list empties; the diff view shows "No changes."
• The new commit appears in the Git History view (a separate activity-bar mode).
• The status strip at the bottom updates the branch's commit count.

To get the commit to the remote, see Push and fetch.

See also

• Push and fetch — getting commits to and from the remote
• Getting started — context for the full clone → edit → commit → push flow