HN user

tobidobi

80 karma

Founder and developer at www.fournova.com. One of the guys behind http://www.git-tower.com.

Posts4
Comments29
View on HN

Thanks for your thoughts on this, Thijs! Here's Tobias, the CEO of Tower.

We want to make sure that Tower can stay a high-quality application in the long run. This means we want to constantly improve the application, add new features, fix bugs, and help users with great customer support. To be able to do that, we need a steady and reliable source of income. The thruth is: for us - a small, self-funded business - a recurring revenue model from a subscription is the only sustainable way to survive.

A model where the user gets to keep the last version after she stops paying for the product does not work for a small business. If you have a team of 1,000 employees like JetBrains, you might be be able to afford this. But not a 7-person team like ours. For two reasons:

(1) First, it doesn't provide the steady and reliable source of income that we depend on. It's the old one-time payment model of the past - which we tried and which did not pay the bills for us in the long term.

(2) Second, and maybe more importantly: very quickly, there are lots of different old versions of the product out there. People want bugfixes, documentation and support for their version, no matter if they're currently paying or if they don't anymore. With a 7-person team, we simply cannot do this. We need to focus all of our painfully limited time on _one_ version and make sure to improve that one.

Most of our users make a simple calculation: "Can Tower help me or my team save some time or prevent some mistakes?" Over the course of the next 12 (!) months, even 1 or 2 hours or a mere handful of mistakes would make this worthwhile. If so, Tower has _easily_ paid itself off.

We offer a free and fully-featured 30-day trial that will help you answer this question for yourself - without any risks or commitments.

Disclaimer: I'm part of the team behind Tower!

Our goal with Tower is to make working with Git easier and more productive, for both Pros and Beginners. We're putting a lot of time and effort into design, workflows, and usability.

Additionally, we're making a lot of Git's "power-features" more accessible: it's not enough to just "somehow provide" a feature like Interactive Rebase. It's only helpful when it's carefully designed and really useable...

With the current Beta version (www.git-tower.com/public-beta-2018), I think we've made great progress to achieve these ambitious goals. However, of course: please see for yourself :-)

Tobias here from the Tower team! I'd like to confirm your assumption: we're indeed working full-steam on improving Tower for Windows (and Mac, of course ;-)

We have quite some exciting features and additions on the roadmap!

Tower for Windows 10 years ago

Tower team member here :-) We are of course working on lots of improvements, especially in the current beta phase. Regarding interactive rebase, by the way, I can say that it's already on the wish list :-)

Tower for Windows 10 years ago

Tower team here: thanks for pointing this out! This is already on our todo list - and, in fact, already being worked on! Won't be an issue for very long ;-)

Tower for Windows 10 years ago

The learning platform on git-tower.com/learn also contains lots of content for learning Git on the command line (without Tower). This is true for both the 150-page book and the 24-part video series.

Hmm... "data corrupting bugs"? Honestly, we haven't heard of a single case in all of our 5 years of being on the market (--> a Tower team member here).

Could you please get in touch with more information via support@git-tower.com ? We'd be happy to help!

Tower 2 12 years ago

Being able to do basic things on the command line is definitely nice. And the question is not command line VERSUS a GUI. Tower, e.g. can be used side-by-side with the command line.

However, Tower help you both become more productive and make fewer mistakes. No one likes to inspect a complex project history on the command line. Getting a visual representation of a conflict helps you resolve it more confidently. Automatically having local changes stashed away prevents problems... There are indeed many scenarios where a GUI is plain helpful - for beginners and pros alike.

Tower 2 12 years ago

In the standard "Merge" dialog (see toolbar button), the option "Always generate merge commit" will make sure the merge is --no-ff.

Tower 2 12 years ago

First, let me say that Sourcetree is an excellent application, too. However, most people that chose Tower over Sourcetree prefer our approach in regard to user interface, workflows, usability, etc. A visual conflict wizard, a new service account manager, automatic stashing... Tower goes a long way to make using Git both as easy and as comfortable as possible.

Tower 2 12 years ago

Interactive rebase is not yet supported. But is already on the roadmap and will come in 2.x.

Sure, you're not limited to code when using Git. Especially when collaborating with others (and more so when working with plain text files), Git can help a lot. I'd suggest you give it a try; both Git and the online version of our book are free!

A lot of teams have, for example, a "development" branch next to "master" through the whole project - and are doing fine.

It's a matter of taste and agreement within the team, I'd say.

First, let me say that SmartGit is an excellent application, too. However, most people that chose Tower over SmartGit prefer our approach in regard to user interface, workflows, usability, etc. Tower goes a long way to make using Git both as easy and as comfortable as possible.

However, don't believe me ;-) I recommend you download the free trial from our website and see for yourself.

I guess it's a combination: a) Granular commits are an essential basis of good version control. Big, bloated commits (maybe even combining code from multiple, different topics) will sooner or later bite you. b) Integrating often. I think you can be successful with long-lived branches, but you need to have more discipline and not forget to re-integrate from time to time. Integrating late will naturally raise the risk of conflicts - because, simply, more changes accumulate.

Same approach here in our team! Basically a very similar model to what "git-flow" propagates. And actually one that is very easy to understand.

Absolutely agree! Rebase is a great alternative to standard merges: it keeps your line of development clean and avoids having tons of "merge knots" in your commit graph.

Actually, this introduction really is independent of a specific GUI application. 95% of it are valid in any case (be it Tower, the command line, or any other frontend you use to access Git).

Preparing the staging area is, in reality, less "work" than you might think. Actually, I can't remember having forgotten to include changes - you'll be getting used to the process in no time. And often you just use the "stage all" switch to simply include all changes. [note: I'm the author of the above post]