Git Town – A high-level command line interface for Git | Hacker News Reader

Git Town – A high-level command line interface for Git

git-town.com

159 pointstnorthcutt85 comments

Those who think a wrapper is going to help their development is in for something when things break and they don't know how to operate things the way they're meant to.

git is an especially poor choice for wrappers. You're hiding the concepts of staged and unstaged information, branches, tags, remotes, submodules. Regardless of VCS, you're setting yourself up for failure when you buy into a third-party tool's workflow rather than knowing what the hell you're doing.

Pick up git as you go along. Rather than a tool doing who knows what behind the scene. If you really goof things when you're starting, don't be afraid to git reset --hard <ref> / git commit --amend + force push, as long as you know where you're at in history.

Git Town doesn't replace Git, nor does it try to shield you from learning how Git works. It shows the Git commands it runs for you, as well as their output. When using it, one should make sure to understand what it is doing.

The thing is, Git is awesome, but intentionally designed as a low-level and generic tool. Using it correctly for particular workflows (like Git Flow or Github Flow) requires running many Git commands for each operation, and is highly repetitive.

Good developers engineer repetition away. Great developers share what they build. Hence Git Town.

> Good developers engineer repetition away. Great developers share what they build. Hence Git Town.

Sure, but a handful of of bash and/or git aliases handles that just fine while also being better suited to a user's particular workflow and easier to learn.

If you're trying to achieve a workflow like 'Git Flow' [1], having everyone in your team attempt it manually with their own home-brew aliases is going to go very badly.

[1] http://nvie.com/posts/a-successful-git-branching-model/

> Good developers engineer repetition away. Great developers share what they build. Hence Git Town.

As someone who has engineered repetition away and shares what he builds, I agree, and admire your gumption.

> intentionally designed as a low-level and generic tool.

git is high level. and opinionated. It has branches and tags baked right in. Compare to SVN or CVS where the support is second class.

> requires running many Git commands for each operation, and is highly repetitive.

I run lots of git commands by hand, and can be pretty verbose in commit messages. I (sort of) try to follow this: https://chris.beams.io/posts/git-commit/

However, to speed things up, I will sometimes at shell prompt use `ctrl-r` and search history a bit, then `ctrl-e` to start scrolling in a line brought back up if I want to both 1. see what I committed last, and 2. get a head start on writing the commit message.

I also find the staging workflow git has (another thing I personally consider high-level, purposeful, opinionated to git, and use regularly) to be very convenient. I can type `git status`, `git diff`, `git diff --cached` to see what's staged and unstaged. I can use `git reset` to unstage a file. Overall, I get more granularity on which files I want to add to that commit. This comes in really handing when reverting, merging and rebasing.

So in my workflow, I don't want to give up control of these things.

Apparently, while I don't use these features, `git bisect` and `git blame` also benefit from being thoughtful with commits.

> It shows the Git commands it runs for you, as well as their output.

I am glad to hear that.

> nor does it try to shield you from learning how Git works

This is what irks me. I view git as high level and opinionated already, and have no way of knowing how it would effect someone learning git. I developed my own habits w/ VCS a long time ago.

That said, leave it up to the people who want to try your project.

(I followed you and starred your repository.)

>This is what irks me. I view git as high level and opinionated already

However high level you think it is, it has no opinion on workflows and there's a need for a tool that will automate and enforce git workflows.

I'm not sure if this tool the answer, but there is a need for some sort of tool like this.

I wrote a hacky 'git sync' script at an old company and it achieved what sending a bunch of developers on a course about git did not (it sped up the workflow and cut down on git errors).

> it has no opinion on workflows

Oh really? Staged/Unstaged + Commit + Push to remote+branch. Branches (I suppose you could chuck everything in master), and opt-in or out of tagging.

Maybe users will keep their own remote repositories ("forks")? Even then, it's still pulling in code with the same history that's going to get reconciled via a merge or rebase. Whether it's "forked" to their own repo or in a branch of the "main" repo, it's all the same in the end.

> there's a need for a tool that will automate and enforce git workflows

There's easy, light-weight branching baked right into git.

They scale locally, remotely, and also work with different user's remotes.

You can also merge branches into branches. You can pull --rebase them as well.

> there's a need for a tool that will automate and enforce git workflows.

Beyond branches and remotes?

> I wrote a hacky 'git sync' script at an old company and it achieved what sending a bunch of developers on a course about git did not (it sped up the workflow and cut down on git errors).

Checking out branches and git add/status/diff/commit/push is that time consuming not only would you need to create a shortcut, other devs would opt-in to it?

I use shortcuts for various things in my shell. I have a .gitconfig in my dot-config files (https://github.com/tony/.dot-config). Personal tweaks for coloring and editor settings, a global gitignore. I'm the kind of a guy who picks up shell plugins for fun to try them, but I know that pushing a tool on top of a VCS on colleagues won't go over well.

What did `git sync` do?

>there's a need for a tool that will automate and enforce git workflows. Beyond branches and remotes?

Yeah, because most branching and merging in a team setting follows a policy. That branch/merge strategy (and naming) is based upon a whole host of things including testing strategies, release schedules, issue tracker used, code review policies, how much you need bisect, etc.

Git is entirely indifferent to those workflows and is as happy to let you follow it as it is to let you commit and push directly to the master branch with a commit message of "fixed shit".

>Checking out branches and git add/status/diff/commit/push is that time consuming not only would you need to create a shortcut, other devs would opt-in to it?

Yeah, when you add stashing, changing to the correct branches, rebasing and pushing, changing back and unstashing it actually does get tedious, especially since I needed to run it about 20 times a day.

I actually didn't even create the script for them originally, I created it for me and they just started using it.

"This is what irks me. I view git as high level and opinionated already,"

I've always found this very strange when it's creators don't feel the same way :)

It was built as a low level content addressable filesystem, it's own docs says they weren't even trying to pretend otherwise until version 1.5.

It's only relatively recently (in the scheme of things) it's tried to become higher level.

I mostly agree but we don't exactly expect devs to call gcc or javac directly. Make, maven, Gradle, etc. all have their place as well.

comparing this glorified set of aliases to Maven and gcc shows a fundamental misunderstanding of said tools

...you're just overanalyzing what I said. I just meant that git stays out of the workflow business and higher level tools might be able to fill in the gap.

I'm not sure I'd use this tool, but I'm not going to get upset if people like it.

This right here, this thing will only attract new developers and will delay the inevitable - which is learning git properly. Reminds of a banana peeling machine ....

The git model for a context where not everyone is a software developer is:

Use these three git commands you have memorized.

If something breaks ask the person who understands git.

That is the reality. Anything that makes people more productive, especially in contexts where the difference between staged/unstaged and all the other things you mention, don't matter, is very very welcome.

While I absolutely agree that you should know how your underlying tools work--and the way I teach people git is to start at the representation level and work up, showing all the file formats in play so people can see how it actually works--I disagree that "git is an especially poor choice for wrappers"... almost all of the tools people normally use with git--the ones that come with git and one might argue "are git"--are also just wrappers (called "porcelain") over lower level tools... most people I know who feel they are sufficient in git only actually know how to use these higher-level tools.

Git Town looks thorough to me. It includes well-written source code in Go, plenty of edge-case error checking, good messages, and excellent feature tests. Kudos!

If you're interested in branch aliases, here are some that may be helpful that I use at GitAlias.com.

topic-start = "!f(){ branch=$1; git checkout master; git fetch; git rebase; git checkout -b "$branch" master; };f"

topic-pull = "!f(){ branch=$(git branch-name); git checkout master; git pull; git checkout "$branch"; git rebase master; };f"

topic-push = "!f(){ branch=$(git branch-name); git push --set-upstream origin "$branch"; };f"

topic-finish = "!f(){ branch=$(git branch-name); git checkout master; git branch --delete "$branch"; git push origin ":$branch"; };f"

branch-name = rev-parse --abbrev-ref HEAD

Why not just `git fetch; git rebase origin/master`?

Personal preference. I prefer to get the local master up to date first. A more-sophisticated alias would/could verify that the local master is buildable, testable, etc. before doing the rebase.

What I like most about using aliases for topic branches (a.k.a. feature branches) is that any team can define its preferred workflow and encapsulate it.

This might also be "dangerous" if git is set to the matching scheme instead of simple, since you don't just pull origin master. I guess anybody simply copying these from here should just be aware and be careful of what they just paste :D.

You should backslash-escape your inner double-quotes.

Thanks for the advice! Done.

Git Town contributor here. Thanks! I love your aliases. That's exactly how Git Town started. Then people kept adding logic to cover edge cases, abort and undo operations, as well as Github and Bitbucket integration. Soon enough we ended with many hundreds of lines of Bash. Hence the recent rewrite in Go.

Git Town is a strict superset of your tools. Your "topic start" == "git hack". Your "topic pull" and "topic-push" = "git sync" (you always want to run both anyways). Your "topic-finish" = "git ship".

Want to join forces?

> squash-merge the password-reset branch into the master branch (this makes it look like a single, clean commit, without the convoluted merge history and the many intermediate commits on your branch)

Is this what most people do? And is this something you can turn off with Git Town? I don't like to to squash-merge, I spend time making sure my commits are as much logical and self-contained units as they can be in my branches, and I want to preserve the ability to revert and/or bisect them later.

It's a trade-off. Many devs don't know how to do that, don't care to do that, will never learn to do that, and for them squash merge is a good option.

For sure. I'm not suggesting anyone else shouldn't; on the contrary just asking if Git Town goes both ways, and whether squash merge is more common in practice?

I would have assumed that a regular (not squashed) merge is more common, and easier to do, because it's the default behavior of "git merge". It takes extra git commands and/or extra non-default arguments to git merge to get a squash merge. My GitHub also doesn't default to squash merge, IIRC... Don't you have to choose squash merge or be told to use it, if you don't otherwise know or care?

I am the opposite, I like shush-merge although I understand and empathize with your view.

My usage is to commit very frequently, like whenever I make a non-trivial fix or small refactor, or when something that touches several files compiles cleanly, or passes a unit test. This is several commits per day. It's practically every file save (if you remember filesystems with explicit version support). So my commit history is very noisy.

When I push back to a shared repo, I want the commit history to document what the change is; various false or partial paths are not enlightening (if I planned to follow strategy 'X', found it did work, and backed out and used algorithm 'Y' then that should go in the source as a comment, not in the metadata.

If my check ins were once a day I might not want to lose them. So I'm philosophically aligned with you, but my commits are so high frequency that the merge functions as a low-pass filter.

I think the person you are responding to probably does something similar to what I do: make a bunch of changes and then use git add -p and possibly even rewriting history if required to come up with tons of clean and cohesive separable changes. I do not have "false or partial paths" as they end up in stashes or get elided from my local history before being pushed; but the high-level task I had, once finished and pushed to a shared repository, definitely contains tons of small change units that I want to keep.

If you squash merge into master, it's much easier to revert it later if something goes horribly wrong.

https://github.com/Originate/git-town/blob/master/documentat...

I think it would be good if the docs had the git commands that are run for a git-town command.

Good suggestion, will add them! Git Town uses Cucumber as living documentation: https://github.com/Originate/git-town/blob/master/features/g...

Hell of work around a few git commands. Screencast, website, promo.

I prefer aliases i configure myself to understand them, most of my colleges don't even bother with that detail of git commands at all and use an ui.

I think that's sort of the point, instead of having aliases, this is a low-effort way to have even people who prefer to use GUI clients (like me) to have an easy-to-use/install unified command line workflow. I'm very tempted.

I am new to programming (less than 1 year) and the insignificance of this project is obvious to me. This looks very well done, but my understanding is that a user friendly wrapper for such a ubiquitous programming tech with already widespread GUIs and pluins is comparable to reinventing a wheel. It's a little frustrating how many projects like this appear to get so much attention and end up on HN, because it makes for a disorienting maze of distractions for newer programmers. I love all the productivity, excitement, possibility but it's still peculiar and debatably problematic.

My best guess is this was a personal project that solved some person(s) problems, and for some reason related to networking or self-promotion, it got the decoration of a full release treatment. What else could cause this?

I know there are zillions of these every day but this seems like one we all can see through. Can anyone share some insight here?

Should I be contributing to the heap of projects like these to further my own career?

What you're seeing and describing is endemic to the entire field of programming. You will encounter it at every level. Frameworks keep being invented left and right which address solved problems, or solve non-existing ones. Meaningless busywork. This will never stop: it is human.

Don't fight it: embrace it. Navigating this wasteland is part of your job. A keen eye for separating wheat from chaff is a valuable asset.

Learning to code is only step 1 in learning to program. Learning how to choose your tools, and what to ignore, is just as important.

This does help me a lot to get this response. I personally actually love downloading and testing small tools and sometimes worry my search for better tools or the promise of better tools is a distraction. But, maybe this willingness to continue the search is just highly correlated with my fascination and interest in becoming a programmer.

> the insignificance of this project is obvious to me

> comparable to reinventing a wheel

> many projects like this appear to get so much attention and end up on HN

> Can anyone share some insight here?

First the HN audience, its core is hackers and startups. These people have certain problems in common, and they are always on the lookout for ways to eliminate them. The hackers build things and the startup people do a lot of management and they are often one and the same.

Secondly good version control is hard to use across a project without swamping new arrivals or accidentally breaking something. Git isn't good enough, but it is what we have.

So like good hackers we take the first, see the second and try and produce something better. This is how we end up with lots of similar looking projects.

Because they are solving real problems being faced by HN users they get upvoted until the comments discover some fatal flaw (leaky? prevents key conflict resolution?).

This author reckons hes solved it, so he gives it the full treatment because it is worth a lot to have __actually__ solved it. If I could resolve git woes by handing a newbie a ten minute video I would be ecstatic.

Remember, it is important to reinvent the wheel [1] though don't waste time on these projects unless you can see a way through.

[1] https://pbs.twimg.com/media/CMyiLuKUwAA6l-V.jpg

Can't resist: https://www.math.uh.edu/~jmorgan/trinity_talk/square_wheel.h...

Point taken! Thanks for the response. While I do have a hard time imagining me recommending this project to anyone (without instead opting for real git commands or gui) your comment encourages me to at least try imagining a future where this project gets surprising widespread adoption and something many maintain and depend on. Like you suggest, it could cut a lot of entry costs if it doesn't double them. ;)

There's all sorts of Git wrappers but I haven't been able to find one that does what I want: a visual interface which will tell you the command line equivalent of what you're doing. Does one even exist?

Granted I am a novice, but have been in film post production and vfx for a long time. I'm not very familiar with any GUIs thay truly reflect proprietary commands.

Nonetheless, I agree. And if you find it, please share.

If you use Emacs, magit is phenomenal. If you use vim, spacemacs and magit are phenomenal. Watch a quick video on it. The command that is run is shown if you press `$`.

I believe source tree shows you the command too if you set it up. Magit is much better than source tree though.

I think you have to reinvent quite a few wheels yourself to become a competent programmer instead of just comfortable gluing services. And maybe, just maybe you will make an actual improvement on the way.

I was sorta hoping someone would offer their take on contributing or creating projects like this for their portfolio. I would be a little self-conscious of having a bunch of 'simplifier' tools in my small portfolio. Is this silly for me to even be thinking?

Git Town contributor here.

This tool was built to help stay sane in large high-velocity development teams. In such environments, one can easily spend an hour (or so) each day resolving merge conflicts. Feature branches go out of sync with the main development branch multiple times a day. One has to keep pulling, merging, or rebasing all open branches regularly to avoid more merge conflicts later. Those things require running many Git commands.

Git Town makes all of this quick,easy, and bulletproof. A lot of people have been using it for years and love it for that.

Apparently our documentation doesn't get this across well enough. We'll add more details.

> I am new to programming (less than 1 year) and the insignificance of this project is obvious to me.

It's a set of helpers, that are useful for the author and useful enough to other people that (1) it was upvoted on HN and (2) it has 643 stars on github (so it appears to be fairly popular).

> my understanding is that a user friendly wrapper for such a ubiquitous programming tech with already widespread GUIs and pluins is comparable to reinventing a wheel

Not really. There are many reasons why these functions are not in core git, however for many people these are common tasks and doing it "manually" with git is a chore.

Just like carpenters craft their own jigs and tools all the time, programmers write scripts to automatic repetitive tasks all the time.

> My best guess is this was a personal project that solved some person(s) problems, and for some reason related to networking or self-promotion, it got the decoration of a full release treatment. What else could cause this?

Most Open Source projects start as personal projects that solved some people's problems, and as others found out that it's useful to them they grow in popularity and become "famous" projects.

This one also took the time to make a site, with an introduction, FAQ, etc, while most other projects only have a github page and a small README.

If this project doesn't seem useful to you, don't spend much time trying to figure out what it is. The best is to be goal driven, i.e. you have a project you want to get through (either for work, school or personal project) and you seek projects that might help you doing that.

> Should I be contributing to the heap of projects like these to further my own career?

Don't create projects for the sake of your career, it will only lead to pointless projects boring for you and everyone else. Build what you need to build, what you want to build, and if you think it might be useful for just one other person feel free to post it online. It's not like the size of the Internet is limited and your project will prevent others from existing.

For example, correctly merging a finished feature branch requires up to 15 individual Git commands!

Am I missing something? Does `git merge` imply fourteen other commands?

Maybe they include things like stashing/popping current uncomitted changes, switching to target branch, pulling source and target branches first, rebasing feature branch onto latest target branch, resolving conflicts, ... ? All of these are things I has to do at one point or another to 'just' merge some feature branch from somebody else into master while I was working on another branch myself. So if they combine all of that in one command including taking care of everything which can go wrong I can imagine getting 15 commands.

> So if they combine all of that in one command including taking care of everything which can go wrong I can imagine getting 15 commands.

My concern would be: what happens when the automation encounters and edge case; what kind of unholy mess would you end up with?

And to be fair, with GitHub and GitLab, doing local feature branch merges has become a very rare event for me in the last 5 years.

Git Town covers a ton of edge cases. Just look at their "features" folder. If something goes wrong, Git Town allows to cleanly abort and undo what it did so far and go back to where it started.

That's a lot safer than the unholy mess that ensues when most people try to run "git reset --hard" or "git push --force" manually.

Edge cases handled properly may be the killer feature of this project, at least for me. With git, as long as I'm in familiar territory it's fine, but when somethings goes off rails my head's working set explodes with options.

Not sure what they're referring to, maybe resolving conficts (`git merge --continue` and such). But at least you may want to delete the topic branch afterwards, locally and on remote.

The "15" is a link to a test case which shows the 15 commands. It's a contrived scenario in my opinion: it assumes that you want to merge a feature branch into the main branch while you're in the middle of working on some other, unrelated feature and have uncommited changes in your working directory.

Hardly a contrived scenario; I run into situations exactly like that at least once a week...

You could just make a new clean checkout in a different directory?

This is what I often do, however with larger repositories (where people have a bad habit of committing files that they probably shouldn't be, blowing out the size of the repo significantly), this can also be slow! But of course, this all comes down to your specific circumstances.

Mine were exacerbated by the fact that the bulk of the team didn't really understand git very well, and bouncing between features at a super rapid pace meant I could get into some slightly odd situations. Nothing a bit of git-fu can't fix normally, but can take a little bit of wrangling or forethought.

You could. I work with Firefox and that code base is huge so it's not a good idea to download 15+ gigs every time you don't know how to do something. Learning the tools is a more sustainable way to go.

Make an external worktree. No need to re-clone the whole repo, nor stashing/commiting your work, switching branch, doing the merge, etc (which you may know how to do, but is a pain if you often need to do so)

https://git-scm.com/docs/git-worktree

That's a neat command... it's also relatively new to git. I hadn't heard about it before... thanks!

I like to keep Git puristic. I have only a few aliases, because I want to operate on every machine the same way.

Git can be intimidating for newcomers. In the last two years, I noticed the pattern that I only use a few essential Git commands in order to resolve a handful of scenarios. I have written them up: https://www.robinwieruch.de/git-essential-commands/ Maybe it helps some people to get started.

I believe knowing the low level commands is very important. I don't think anyone should use Git Town without learning everything covered in your article. Git Town prints every* Git command it runs and what branch it is run on. That was my first contribution to the project as I wanted to know exactly what the tool was doing.

* Git Town runs other git commands to inspect the state of things (for example: what is the current branch, are there any uncommitted changes). These are not printed but each one that changes the state (for example: checking out another branch, fetching updates, merging branches) are printed

I will give it a shot! Thanks for the clarifications :)

Don't bother, learning GIT is a transferable skill, this will be thrown out as soon as you join a proper development team . Gimmicky at best

I don't see much utility in this but I certainly don't restrict the toolset my developers use and would be perfectly fine with them using this on any of our machines, especially if it made their lives easier.

This tool is not meant to replace Git. Each command runs a series of git commands (all of which are printed out) which may be different based on the state of your repository. I would advise against using Git Town without understanding Git.

Another great alternative that I use every day is https://hub.github.com, especially if you work with GitHub.

Hub is awesome, and orthogonal to what Git Town does. You can use both together, though.

So this is for people who don't know how to use aliases (bash or git)?

They had to write thousand lines of code in Go instead of these aliases. Startup aura!

Git Town started out as Git aliases written in Bash. Version 3 was many hundred lines of Bash, pushing it beyond what Bash was designed for. At some point it got ridiculous, and we got requests for Windows support, as well as better integration with the Github API. Hence the rewrite in Go.

I still don't see the killer feature here. It just throws around ton of commands, most of which are completely unnecessary.

Over the years, there have been many "friendly interfaces to git", in both UI or command line form.

They all suffer from the same issue: in the face of conflicts they just failsafe to good old git.

I think these tools are good if you want to do something more productively but in the end you will still need to know about git.

I'm not sure this is trying to prevent anyone from needing to learn the actual git commands. (Note that the abstraction intentionally leaks by showing the commands that are run.) It appears to be more of a tool for experienced users on centralized teams to save some time typing.

Slick stuff.

But can you use this in practice and not know what git is doing? Aka is this really not a leaky abstraction?

I ask sincerely; having known git for years I can't objectively answer this.

As an experienced git user, I'd use this on projects with a central repo, if only because it saves some typing.

It shows the Git commands it runs, as well as their output. So, you know exactly what Git is doing.

Seems interesting but I don't personally like using these kind of projects.

Having a wrapper around another technology or tools to make things easier to use, encapsulates many more important concepts that you have to know as a good developer. I don't think giant tech companies use these kind of tools as well.

Giant tech companies basically use their own version control systems. Facebook uses something forked from Mercurial, I think, Google has a Perforce derived one, etc.

They basically take the approach presented here to 11.

Git Town is meant to be a wrapper around Git but an extension. The commands it adds are suitable for particular workflows where you would otherwise be running the same series of git commands. It prints out all the Git commands it runs and the output of them.

I think Git Town is best used only after someone learns Git (and has possibly run through the workflows by hand).

When I saw the name, I thought it was a simcity game with git :P

The command-line interface is what I loved about darcs. Too bad it never got the mind share because of early performance problems.

Seems like a more lightweight version of the 'arc' cli tool of Phabricator (which I really like BTW)?

Shouldn't this whole thing just be a pull request into git itself?

No. Git tries to be agnostic to your workflow. Also, some of the commands are tailored for github, which is not the only git host. See gitlab, gogs, gerrit, etc...

Looks very similar to Git Flow

Git is a great foundation for source code management.

No. Fucking marketing doublespeak. Git is great for source-code management. Don't start your pitch by trying to redefine and reposition Git. You lost me right there.

Reply on news.ycombinator.com