A lot of Git is driven by the hype around it. Most people and small teams won't need most of Git's features. The one advantage of Git is working on multiple branches; but then again, Mercurial would be a superior choice for that.
"Just use Git because everyone uses Git" - which is the most common excuse - is horrible, leading to a VCS monoculture.
I think cheap feature branches are the killer feature of git compared to centralized SCM systems. And those are useful for any team with at least 2 people. Git is also super fast!
Even just a single person benefits from using a good DVCS system over SVN/similar. SVN etc. are painfully slow, can't deal with branching or even just properly tracking changes, and are in so many other ways obsolete.
However, just picking Git because everyone picks Git is stupid, as is the case with most tools. Mercurial definitely is better for most uses. Then there are special cases (e.g. games etc.) where something like Plastic SCM is better.
The only workable GUI I know for Git is GitKraken, and that's a fairly recent thing. SourceTree supports both, but isn't great on either. TortoiseHG is what I typically use with Mercurial.
The worst thing about Git is that it was written by a kernel programmer, a person who has literally no idea of how human beings function and think, and really didn't care. Most commands in Git are much more confusing than they need to be, whereas Mercurial is trying to work in a predictable and understandable manner.
Just the amount of people who "proudly" present how many aliases they've set up on their machine to make dealing with git more reasonable is a good sign of this. I've never found a need to make a single shell alias to work with Mercurial.
It really terrifies me how many people think using Git from the CLI makes you cool or something, and then because they can't figure out how it works they just do a blind git add -A && git commit -m '...' && git push -f .. and people seriously just use push -f instead of trying to understand what is wrong when they've got 5 heads on a branch that should be merged, or they've not pulled other people's changes.
With a GUI you tend to see exactly what changes have been made, you can view the per-file side-by-side diffs easily to confirm it's what you think it is, commit what you wanted, and then see the different heads easily.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
The only workable GUI I know for Git is GitKraken, and that's a fairly recent thing. SourceTree supports both, but isn't great on either. TortoiseHG is what I typically use with Mercurial.
There's also Git-Tower (git-tower.com). But it's Mac/Win only :-(
A lot of Git is driven by the hype around it. Most people and small teams won't need most of Git's features. The one advantage of Git is working on multiple branches; but then again, Mercurial would be a superior choice for that.
"Just use Git because everyone uses Git" - which is the most common excuse - is horrible, leading to a VCS monoculture.
I think cheap feature branches are the killer feature of git compared to centralized SCM systems. And those are useful for any team with at least 2 people. Git is also super fast!
Can't say much about the Mecurial part but you're right about that most - not even small - teams don't need that much of the feature set.
git add, commit, pull, push, branch, status, log and reset from time to time.
Also there are some really nice GUI available.
Even just a single person benefits from using a good DVCS system over SVN/similar. SVN etc. are painfully slow, can't deal with branching or even just properly tracking changes, and are in so many other ways obsolete.
However, just picking Git because everyone picks Git is stupid, as is the case with most tools. Mercurial definitely is better for most uses. Then there are special cases (e.g. games etc.) where something like Plastic SCM is better.
The only workable GUI I know for Git is GitKraken, and that's a fairly recent thing. SourceTree supports both, but isn't great on either. TortoiseHG is what I typically use with Mercurial.
The worst thing about Git is that it was written by a kernel programmer, a person who has literally no idea of how human beings function and think, and really didn't care. Most commands in Git are much more confusing than they need to be, whereas Mercurial is trying to work in a predictable and understandable manner.
Just the amount of people who "proudly" present how many aliases they've set up on their machine to make dealing with git more reasonable is a good sign of this. I've never found a need to make a single shell alias to work with Mercurial.
It really terrifies me how many people think using Git from the CLI makes you cool or something, and then because they can't figure out how it works they just do a blind
git add -A && git commit -m '...' && git push -f.. and people seriously just usepush -finstead of trying to understand what is wrong when they've got 5 heads on a branch that should be merged, or they've not pulled other people's changes.With a GUI you tend to see exactly what changes have been made, you can view the per-file side-by-side diffs easily to confirm it's what you think it is, commit what you wanted, and then see the different heads easily.
"It really terrifies me how many people think using Git from the CLI makes you cool or something[...]"
Perfect point
I don't think it's necessarily "cool" but I genuinely have trouble using GUIs for these sort of things.
"Then there are special cases (e.g. games etc.) where something like Plastic SCM is better."
...
There's also Git-Tower (git-tower.com). But it's Mac/Win only :-(
Sadly. Need to teach new developer how to use Git. Do you have any suggestion for tutorial?
I learned how to use git from this course in udacity, it's pretty good udacity.com/course/how-to-use-git-...
The Atlassian Git Tutorial is the best introduction to git I've found.
Don't do that. Teach them the magnificent variety instead.
What do this mean?
Why do you want to teach Git when you can teach better systems?
Which is better? As Git is selected by corporate, I need to teach new developer how to use this.
Not exactly a tutorial, but Gihub has some nice Cheatsheets: services.github.com/on-demand/reso...
I use learngitbranching.js.org for the beginners to learn the basic commands. With this game they can do so in a few hours on their own. HF.