
Git Town – A high-level command line interface for Git - tnorthcutt
http://www.git-town.com/
======
git-pull
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.

~~~
kevingoslar
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.

~~~
git-pull
> 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/](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.)

~~~
crdoconnor
>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).

~~~
git-pull
> 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](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?

~~~
crdoconnor
>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.

------
jph
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

~~~
jwilk
You should backslash-escape your inner double-quotes.

~~~
jph
Thanks for the advice! Done.

------
dahart
> 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.

~~~
MBlume
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.

~~~
dahart
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?

------
rojoca
[https://github.com/Originate/git-
town/blob/master/documentat...](https://github.com/Originate/git-
town/blob/master/documentation/commands/sync.md)

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

~~~
kevingoslar
Good suggestion, will add them! Git Town uses Cucumber as living
documentation: [https://github.com/Originate/git-
town/blob/master/features/g...](https://github.com/Originate/git-
town/blob/master/features/git-town-
sync/current_branch/feature_branch/no_conflict/with_tracking_branch.feature)

------
sigi45
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.

~~~
superlopuh
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.

------
gt_
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?

~~~
Normal_gaussian
> 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](https://pbs.twimg.com/media/CMyiLuKUwAA6l-V.jpg)

~~~
jstimpfle
Can't resist:
[https://www.math.uh.edu/~jmorgan/trinity_talk/square_wheel.h...](https://www.math.uh.edu/~jmorgan/trinity_talk/square_wheel.htm)

------
btym
_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?

~~~
stinos
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.

~~~
falcolas
> 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.

~~~
kevingoslar
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.

~~~
Jare
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.

------
rwieruch
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/](https://www.robinwieruch.de/git-essential-commands/) Maybe it helps
some people to get started.

~~~
charlierudolph
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

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

------
throwme_1980
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

~~~
SmellyGeekBoy
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.

------
georgecalm
Another great alternative that I use every day is
[https://hub.github.com](https://hub.github.com), especially if you work with
GitHub.

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

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

~~~
kevingoslar
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.

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

------
partycoder
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.

~~~
qguv
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.

------
paulddraper
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.

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

------
afshinmeh
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.

~~~
oblio
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.

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

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

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

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

~~~
roblabla
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...

------
romanr
Looks very similar to Git Flow

------
mdekkers
_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.

