High-quality client, new version sounds like it'll be on par with Sourcetree features while retaining a decent GUI. Sourcetree is marvellous, but overly complicated to use.
SourceTree crashes like all hell for our team. I like the pretty visualisation of the branches, and it's not bad for git newbies, but it actually feels like a relief using the command line most of the time.
Is there a reason to use SourceTree a lot? I only fire up Source Tree when I'm feeling too lazy to compose a search command from the terminal. Of course, `git log | grep phrase` usually does the trick but if I need anything fancier (date ranges, for instance) I'll just fire up ST.
I use it mostly for the graphs... We work between a ton of branches and it's nice to see the visualization. Also, it's a lot faster when I have to push multiple branches to multiple repos (looking through 2 remotes with 7 branches each right now).
Yeah, the bugs (it occasionally needs a full restart) in SourceTree definitely hold it back. I'm willing to put up with them for all the other features, but I can understand how others wouldn't.
I think the support for squashing that Tower has, is far better (or easier to use) than how interactive rebase works in SourceTree. In fact that is the reason I bought Tower. You can squash on merge. In SourceTree I was not able to squash without craeting aditional commits on the way.
I liked the original Tower when it came out, and I paid the £50 or whatever it was since it was so much better than everything else. I don't know if it can compete with SourceTree any more though: pretty much all of its advertised new features are already present in SourceTree, which is free.
What nailer said. Works great on non-GH repos without any complaints, just maybe non-standard workflows and mentality.
It's actually what I recommend to colleagues who aren't comfortable with git, but we find it to be better than any other version control or [insert LaTeX collab startup here] for writing academic articles.
I wrote my thesis with latex + git. Merging can sometimes be wonky, but no wonkier than usual.
I had my sister review my thesis for grammar and spelling, she doesn't do git, so I checked out a coy in a dropbox folder and shared it with her. She made her edits in the folder, and would send me emails as she finished each chapter. After she finished a chapter I would check in her changes and merge the diffs with FileMerge.
Worked pretty well, though we only collaborated on text, I never merged figures or equations. I also had a cron job that would render the head of the master and put it on my website so my advisor and committee members could check in on my progress.
It works quite well, in my case. There is only one pitfall: conflicts. Since two edits on the same line become a conflict, this can easily cause headaches unless some sort of agreements or conventions are in place. For somebody acquainted with git, it's not bad, but typically if somebody doesn't use git, svn, etc. and they have a conflict, the merge process is far from painless. The best way to avoid this is simply to add newlines as frequently as possible, after every sentence as a minimum; also, have some sort of understanding with your co-authors about who is working on which sections. This may or may not be easy for you, depending on the technical content of your writing.
For my own notes and papers, it's great in all the ways that git is supposed to be: keeps me organized, keeps things backed up (I use BitBucket, free unlimited collaborators with a .edu address), and makes me feel better because I have more control over the whole process (as opposed to Dropbox or Google Drive).
I've been a big fan of GitHub for Mac since it first launched, and it still gets regular updates. It won't be easy to convince me to switch, but I'm all for improving tools that are such a big part of the workflow.
28 comments
[ 1.7 ms ] story [ 63.0 ms ] threadFor actual commiting, branching, etc I just use the terminal.
I went to just using git on the command line, and the GitHub mac app for doing commits
http://rowanj.github.io/gitx/
It's actually what I recommend to colleagues who aren't comfortable with git, but we find it to be better than any other version control or [insert LaTeX collab startup here] for writing academic articles.
Edit: for clarity.
What are your experience with using latex + git?
I had my sister review my thesis for grammar and spelling, she doesn't do git, so I checked out a coy in a dropbox folder and shared it with her. She made her edits in the folder, and would send me emails as she finished each chapter. After she finished a chapter I would check in her changes and merge the diffs with FileMerge.
Worked pretty well, though we only collaborated on text, I never merged figures or equations. I also had a cron job that would render the head of the master and put it on my website so my advisor and committee members could check in on my progress.
For my own notes and papers, it's great in all the ways that git is supposed to be: keeps me organized, keeps things backed up (I use BitBucket, free unlimited collaborators with a .edu address), and makes me feel better because I have more control over the whole process (as opposed to Dropbox or Google Drive).