gitin

gitin is a commit/branch/status explorer for git

gitin is a minimalist tool that lets you explore a git repository from the command line. You can search from commits, inspect individual files and changes in the commits. It is an alternative and interactive way to explore the commit history. Also, you can explore your current state by investigating diffs, stage your changes and commit them.

Features

• Fuzzy search (type / to start a search after running gitin <command>)
• Interactive stage and see the diff of files (gitin status then press enter to see diff or space to stage)
• Commit/amend changes (gitin status then press c to commit or m to amend)
• Interactive hunk staging (gitin status then press p)
• Explore branches with useful filter options (e.g. gitin branch press enter to checkout)
• Checks before committing and pushing: gitin status and gitin push run your checks first, or skip them if you choose to
• Fast on large repositories, the history is loaded and searched in the background
• Convenient UX and minimalist design
• See more options by running gitin --help, also you can get help for individual subcommands (e.g. gitin log --help)

Installation

Linux and macOS are supported. gitin runs git to read repositories, git 2.18 or newer is required.

• Download the binary for your platform from the latest release. To check that it was built by this repository's release workflow, run gh attestation verify <archive> --repo isacikgoz/gitin
• Or, install it with Go: go install github.com/isacikgoz/gitin/cmd/gitin@latest

Mac/Linux using brew

The tap is recently moved to new repo, so if you added the older one (isacikgoz/gitin), consider removing it and adding the new one.

brew tap isacikgoz/taps
brew install gitin

Usage

usage: gitin [<flags>] <command> [<args> ...]

Flags:
  -h, --help     Show context-sensitive help (also try --help-long and
                 --help-man).
  -v, --version  Show application version.

Commands:
  help [<command>...]
    Show help.

  log
    Show commit logs.

  status
    Show working-tree status. Also stage and commit changes.

  branch
    Show list of branches.

  push
    Push the current branch, optionally after running your checks.


Environment Variables:

  GITIN_LINESIZE=<int>
  GITIN_STARTINSEARCH=<bool>
  GITIN_DISABLECOLOR=<bool>
  GITIN_VIMKEYS=<bool>

Press ? for controls while application is running.

Configure

• To set the line size export GITIN_LINESIZE=5
• To set always start in search mode GITIN_STARTINSEARCH=true
• To disable colors GITIN_DISABLECOLOR=true
• To disable h,j,k,l for nav GITIN_VIMKEYS=false

Checks before committing and pushing

Committing in gitin status (c, or m to amend) asks whether to run the commit checks first or to commit without them. gitin push shows what it pushes and asks the same about the push checks. q cancels.

Write your checks in .git/gitin/config.yml. It is never committed, so it needs no .gitignore entry and works in any repository:

commit:
  checks:
    - name: Format
      run: test -z "$(gofmt -l .)"
push:
  checks:
    - name: Lint
      run: golangci-lint run
    - name: Tests
      run: go test ./...
    - name: Build
      run: |
        make build
        ./scripts/smoke-test.sh

To share checks with your team, commit them in a .gitin.yml at the root of the repository, in the same format. Its checks run first, then your own.

• Checks run one after the other in the root of the working tree, their output is shown as it comes. All worktrees of a clone use its .git/gitin/config.yml.
• Commit checks see what gets committed: unstaged changes of tracked files are set aside while they run, in .git/gitin/unstaged.patch, and restored afterwards. Untracked files stay. If a check changes a file you also changed without staging, its change is undone so yours comes back.
• If a check fails, gitin asks whether to commit or push anyway. Ctrl-C stops the running check and cancels.
• run is a shell command. Commands with : in them have to be quoted, a | block is the easiest way.
• git's own pre-commit and pre-push hooks still run.
• A branch goes where git push sends it. If git can't tell, e.g. for a branch without upstream or one whose upstream has another name, it goes to a branch with the same name on its push remote (branch.<name>.pushRemote, remote.pushDefault or the upstream's remote, else origin or the only remote). A branch without upstream tracks it.

Development

Go and git are the only requirements.

go run ./cmd/gitin --help   # run gitin
make test                   # unit and end-to-end tests
make coverage               # the same with a coverage report
make screens                # rewrite the screens of the end-to-end tests after a UI change
make dist VERSION=v1.2.3    # release archives for Linux and macOS

The end-to-end tests in e2e run the gitin binary in a pseudo terminal, type keys and check the repository and the screen of a terminal emulator, colors included. The screens worth reviewing are kept in e2e/testdata/screens, so a change to the UI shows up in the diff. CI runs them on Linux and macOS and with the oldest supported Go and git versions, and checks lint, workflows and known vulnerabilities. Pushing a v*.*.* tag runs CI and drafts a release with binaries for Linux and macOS and their build attestations, publish it on GitHub after reviewing the notes.

Contribution

• Contributions are welcome. If you like to please refer to Contribution Guidelines
• Bug reports should include descriptive steps to reproduce so that maintainers can easily understand the actual problem
• Feature requests are welcome, ask for anything that seems appropriate

Credits

See the credits page

License

BSD-3-Clause