I understand that collaborating on code is a hard problem. But if this is the simplest solution, part of me wants to throw it all in the trash and start over. It's just not good enough.
I read a funny quote somewhere, it basically said that git is a great library for building a DVCS...
Basicailly, I agree with you. What I'd personally like to see more of is an easy way for a company to define a workflow for version control, using git as the underlying mechanism, that fits exactly how they want it to work (think, if the company wants Git Flow, or some other workflow, they define it in my imaginary tool), but for the most part the developers never have to drop down to git to use it. They have an abstraction layer over the top of it.
I saw a paper, gitless, I think it was, that is trying to do something similar but less ambitious. Perhaps in the future we'll see stuff like it. GitHub Desktop and Atlassian Stash also do something similar, but not quite what I'm getting at.
This is a fantastic idea. Even the "nice" git tools like Github's desktop app don't abstract over tracked files and branches and all the confusing git plumbing. It'd be so much better to just be able to click "I'm working on a new feature" and "I'm done with the new feature."
I believe that version control should really get out of your way, and right now, that definitely isn't the case. To me, all the arguments about git's power just sound like "why use Dropbox when you can just sync your files with FTP?"
> It'd be so much better to just be able to click "I'm working on a new feature" and "I'm done with the new feature."
Maybe, but it might instead be better to ask people to invest a small amount of time in learning to use tools that make them more effective at doing their job. "I'm working on a new feature" and "I'm done with the new feature" are, sadly, not actually expressive enough concepts to deal with the problem.
Syncing files with FTP is pretty much at the same conceptual level as "Use Dropbox". Git solves problems significantly more complicated than "I'm working on a new feature / I'm done working on a new feature".
EDIT: when I say "conceptual level", I mean, "what you do with it", not "how easy it is to use". Obviously, Dropbox is more usable than FTP. My claim is that Git provides a much different level of power than "I'm working on a feature/I'm done with a feature", which is not a sufficiently expressive concept to deal with software development.
> Syncing files with FTP is pretty much at the same conceptual level as "Use Dropbox".
I disagree. My mom loves Dropbox -- she just sticks a file in a folder like she always does and it's magically synced. If she were to use FTP, she'd have to set up a server, remember login credentials or find her public key, and grab an FTP client. And not every client supports automatic syncing either, so she might have to manually trigger a sync.
Of course, FTP has way more power and flexibility than Dropbox, just like git vs <proposed VCS>. If your workflow is especially complicated, I'm sure all the git functionality comes in handy and an abstraction would be a hindrance. But most workflows, I'd argue, don't need all the plumbing.
That's the app was trying think of! Cheers :) what I want to see, is a way of building those work flows in sourcetree, and pushing that out to developers. Would be awesome... And I think I might try and hack on it perhaps.
Which part do you dislike? I think the basic idea of (1) Create a new branch (2) Develop your feature and commit (3) merge your changes back to master, those steps are as simple as it can possibly be. So is it that this article recommends rebasing (something you don't need to do) what makes it seem non-simple? Or is it the commands themselves (git doesn't have a great ui)?
"At this point solve any conflicts that come out of the rebase"
Hide (in my experience) huge amounts of complication -- this can get very hairy, and it isn't discussed at all how you do it (and it's more complex than any of the rest of the stuff shown here).
perhaps because it's not in any way different than "At this point solve any conflicts that come out of the merge"? isn't conflict resolution usually done on a case-by-case basis?
So if you e.g. want to abandon the conflict-fixing, and do some things on your branch to make merging easier first, you've got to use a special command, and it's different depending on whether you were merging or rebasing (which is still a great improvement over a year or so ago, when you had to do an incantation like git reset --hard HEAD^). Contrast with svn where abandoning a merge is just a "svn revert" like any other.
Agree 100%. Whenever go beyond the very basic functionality in git I have to think so hard about what I'm doing that I lose flow on my actual development. In most cases I find using git to be more daunting than actually writing code.
Maybe I just don't use it enough. Right now I'm in a job where my git workflow is: pull, (do some work), commit, push.
