[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/

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

[DannyBee]

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

[nolemurs]

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

[allover]

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/