git-open: Open a Repository's Web Page From the Command Line

The gap git-open fills between the shell and the browser

After a push, the next thing most developers do is find the repository page. That means switching to a browser, finding the tab, or scrolling through shell history for the URL. git-open removes that step. The README describes the tool as: type `git open` to open the repo website (GitHub, GitLab, Bitbucket) in your browser. It reads the remote that is already configured in the current repository, works out the corresponding web URL, and hands it to the default browser.

The audience is narrow and specific. It is for people who already work inside a Git repository in a terminal and want the web view of that repository without leaving it. It is not a Git client, it does not touch commits or branches, and it does not replace a forge's web interface. The script is written in Shell and the repository is licensed under MIT.

How git-open derives a URL from your remotes

The mechanism is URL translation, not an API call. git-open inspects the remotes of the current repository, defaults to `origin`, and maps the remote URL onto the web host that serves it. The README lists the hosts it can guess: github.com, gist.github.com, gitlab.com, custom hosted GitLab, bitbucket.org, Atlassian Bitbucket Server, Visual Studio Team Services, Team Foundation Server, AWS Code Commit and cnb.cool. Anything outside that list is not handled unless a custom remote is configured.

Branch and path selection are handled by arguments. With no arguments, the tool targets the current branch. Passing a remote name changes which remote is used; passing a remote and a branch changes the branch as well. The `--commit` flag targets the current commit, and `--issue` maps a branch name that follows the `issue/#123` convention onto the matching issue page. The README notes that `--issue` currently only works with GitHub, Visual Studio Team Services and Team Foundation Server, so that flag is narrower than the rest of the tool.

The `--suffix` option appends a path segment to the generated URL, which is how you reach pages such as the pull request list without knowing the URL pattern by heart. Every one of these behaviours is string manipulation on the remote URL plus the branch name. There is no network call to the forge, which is why the tool is fast and also why it cannot tell you whether the page you are about to open actually exists.

Installing git-open and opening your first page

The README gives a preferred installation path and a package manager path. The preferred one is to put the `git-open` script somewhere on your `PATH`, either by adding its directory to the `PATH` environment variable or by copying the script into a directory that is already included, such as `/usr/local/bin`. The npm route is a single command and is the easiest to remember:

npm install --global git-open

After that, `git open` is available as a Git subcommand. The package also exposes a second binary name, `git-home`, so `git home` works as an alias. From inside any repository with a supported remote, the bare command opens the current branch:

git open

The README's example shows this opening `https://github.com/TRACKED_REMOTE_USER/CURRENT_REPO/tree/CURRENT_BRANCH`. If you want to see the URL before a browser tab appears, `--print` (or `-p`) prints it and stops there. That is the flag to use when you are scripting or when you want to confirm which remote was picked before something opens:

git open --print

Two more forms cover the common variants. Passing a remote name targets that remote instead of `origin`, and passing a remote plus a branch targets a branch you are not currently on. The `--suffix` flag appends a path to the generated URL, which the README illustrates with the pull request list:

git open --suffix pulls

On Windows there is no npm-free equivalent in the README. The PowerShell instructions define a function that shells out to the Git for Windows bash binary and then alias it, and the `cmd` instructions simply say to save the script somewhere reachable through `%PATH%`. Zsh users have plugin manager entries for Antigen, Oh-My-Zsh, Zgen and zplug; Bash users have Oh-My-Bash. Each of those is a documented install path, not a recommendation, and the choice mostly depends on which plugin manager you already run.

Where git-open breaks or is the wrong choice

The sharpest limitation is the supported host list. If your repository lives on a forge that is not listed, git-open has nothing to derive a URL from. The README mentions configuration for custom remotes and custom domains, and points to the man page for the details, but the README body does not spell out the configuration keys. Anyone adopting this for a self-hosted server should read `git-open.1.md` first, because that is where the configuration is documented.

The second limitation is the issue workflow. `git open --issue` depends on a branch naming convention, `issue/#123`, and even then the README says it only works with GitHub, Visual Studio Team Services and Team Foundation Server. Teams that name branches after tickets in a different format, or that use GitLab or Bitbucket, get nothing from that flag.

The third is more structural. Because the tool builds URLs by string manipulation rather than querying the forge, it will happily open a page for a branch that was never pushed. The result is a 404 in the browser, not an error in the terminal. That is a reasonable trade for speed, but it means git-open is a convenience wrapper, not a source of truth about repository state. It is also the wrong tool for anything beyond opening a page: it does not create pull requests, comment on issues, or interact with a forge API. The README points to `hub` for complete GitHub opening support, and that framing is honest about the scope.

How git-open compares with hub and the other git-open forks

The README's alternative section is unusually direct, and it is worth taking at face value. `hub` is described as the official GitHub project providing `hub browse`. The difference in approach is breadth: hub is a full GitHub command-line wrapper, so opening a page is one feature among many, while git-open is a single script whose only job is the URL. If you already use hub, `hub browse` covers the same ground and you gain nothing by adding git-open. If you want one small script and no GitHub-specific dependency, git-open is the smaller thing.

There is also a Homebrew alternative with the same name that only works with GitHub but can open user profile pages, and a third implementation by gerep that supports a few providers and opens the default Bitbucket view rather than the source view. The Bitbucket detail is a real behavioural difference, not a cosmetic one: it changes which page you land on. And the README credits jasonmccreary's original `gh` as the fork point, which explains why the tool's scope has stayed this narrow. The practical upshot is that there are at least four tools with overlapping names and different host coverage, so the one you install matters.

Maintenance, upgrades and the MIT licence

The last push to the repository was on 2026-05-25, and the repository is not archived. The published releases tell a different story about cadence: v2.1.0 was tagged on 2018-12-03, v2.0.0 on 2017-12-01, and 1.1.1 on 2016-08-12. The changelog stops at the 2018 release. Meanwhile `package.json` reports version 3.1.0, so the npm package has moved past the newest tagged release. Anyone pinning a version should check both the release list and the package metadata, because they do not agree.

The upgrade cost is close to zero. The installed artifact is a shell script, the npm package declares `preferGlobal`, and there is no runtime service to restart. Updating means reinstalling the package or replacing the script on your `PATH`. If you install through a Zsh plugin manager such as Antigen or Zgen, the README states that the manager handles cloning and periodically checks for updates on its own, which moves the upgrade decision to the plugin manager.

Development dependencies are the interesting maintenance signal. The test suite runs on bats, and `npm test` chains the unit tests with `shellcheck`, `markdownlint` and `eclint`. That means a change to the script has to survive both behavioural tests and a shell linter, which is a stronger setup than many single-file shell tools carry. The MIT licence is permissive and the README states the copyright holders as Jason McCreary and Paul Irish. Redistribution and modification are allowed under those terms; this is a description of the licence text, not legal advice.

Editorial conclusion

git-open suits anyone who lives in a terminal and constantly pastes repository URLs into a browser. It is the wrong tool if you need to create pull requests, manage issues or work with a forge that is not in its supported host list. Before adopting it, check the git-open.1.md man page for the configuration keys, because the README itself does not document them, and confirm your remote host is one of the supported providers.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. paulirish/git-open on GitHub
4. README
5. Releases