How do I teach git to a teenager

Question

I like Git, or at least the idea of it. However I can not get my head around how to use it. Therefore I would not like to teach it.

(This question is about learning to use Git. Not about comparing it to other revision control systems.)

I have used a range of revision control systems: SCCS, ClearCase, RCS, CVS, and Subversion. I then tried to learn Git. In reading the manuals I got a full understanding of its internals. I even managed to use it, but after a few days I would forget how to use it. The interface seems unintuitive. I then adopted Mercurial (hg) — a similar, but easier to use revision control tool.

I have noticed that Git is very popular, and maybe superior to Mercurial (internally, if not from a usability point of view). And am therefore thinking of giving it another go.

What can I do to make this journey easier for me?

What good user interfaces should I adopt?

I am not interested in proprietary tools; All tools should be Free Software / Open Source. They need to be available for GNU/Linux and Microsoft Windows (I have to use the latter at work).

---

Who are the learners?

• Myself (a software engineer > 20 years experience of revision control systems).
• My pupils (age 11 to 18), if I find it easy enough to learn my self.

My preference for user interfaces are

• Unix (GNU/Linux) command line.
• Unix (GNU/Linux) GUI.
• Microsoft's Windows GUI.
• Microsoft's command line.

So it is important, for me, to have a good command line tool, on my GNU/Linux machine. And important to have a good, and the same, GUI on GNU/Linux and Microsoft Windows.

My goals

• To use the tool to store the history of my, and pupils, projects.
• To be able to look at past history.
• To be able to revert to past state.
• To merge and resolve conflicts.
• To not be un-necassarily serprised.
• To never think, that life would be easier without it.
• Have a smooth progression from the basics (that should be very easy), to the complex (that should be as complex as necassary, but no more).

I am not against command-line usage (it is my favourite way to use the computer), I am against cryptic, hard to remember commands, that have surprising results.

Answer 1

I highly recommend this tutorial: http://learngitbranching.js.org/

It uses a visual representation of the internal state combined with actual commands in a sandbox environment along with a step by step walk-through that I found really helpful in wrapping my head around what each command actually did when I was new to Git.

Answer 2

First, realize that you can't learn everything about Git all at once. Learn the basics to get you going. Learn the other commands as needed. Practice a lot. Git is awesome.

I suggest that you learn Git from the terminal. That will build an appreciation for the IDE plugins and GUIs later. Plus, it's helpful to understand what's going on under the hood. Here is a good interactive Git tutorial. Here's another, more comprehensive one.

Windows

You can download a Git client for Windows here: https://git-scm.com/ . This will give you a light bash terminal that you're already familiar with.

Mac

Try a Git command from a Mac terminal. It will prompt you to install Git (if needed).

Gnu/Linux

A lot of distros come with git. To install on any Debian based system, such as Ubuntu type sudo apt-get install git.

What's really going on?

This is a great video on what's really going on in Git. I highly recommend it: https://maryrosecook.com/blog/post/git-from-the-inside-out-talk

Connecting to GitHub, Bitbucket, etc.

Soon, you'll want to connect your computer to a Git server. These instructions will help you create a local, public SSH key that you can paste into your GitHub, Bitbucket accounts. This will give you access to your remote repos. By the way, you can create free accounts at GitHub, Bitbucket, or GitLab.

Answer 3

If you already use an IDE, this could be the right way for you:

Git support in your IDE

Many IDEs come bundled with Git support:

• Visual Studio Code has maybe the best Git integration I've ever seen.
• Eclipse uses EGit for Git integration.
• The JetBrains IDEs (IntelliJ, PyCharm etc.) also provide Git support.

All of those IDEs run on most common platforms (e.g. Linux, Mac, Windows) and look more or less the same there. This would mean you can use the Git client you know at home and at work if you use the same IDE at both places.

Normally, the Git support integrates quite well with the programming workflow. The Git clients are often quite mighty, but always accessible using a comfortable GUI, which could help as there are no terminal commands to memorize. However, you should keep the Git concepts in mind - depending on the IDE, the built-in Git client will follow those concepts more or less closely.

---

I personally use the built-in Git integration of various IDEs in my day-to-day work and am very happy with it, so I could recommend it to everyone who doesn't want to experiment but just wants to have a good-working Git client.

Answer 4

1) Use the built-in Git GUI

Git actually includes a built-in user interface known as git-gui which is great for novices learning Git for the first time. It's fairly simple to use, comes standard with Git, and is available on Windows, Mac OS X, and Gnu/Linux.

Git-gui has a very simple interface that visually displays the process of staging files, creating commits, viewing project history, amending the last commit, creating branches, local merging, fetching/pushing to remote repositories. It also includes easy access to Git Bash in your command line of choice for more advanced commands or, more commonly, manually correcting any errors that may occur. (And let's be honest, that happens a lot when using Git)

What I like most about Git GUI is that, since it comes as a built-in feature of Git, it doesn't make any attempts to oversimplify or obfuscate the process. Each action can be easily understood as a standard git command.

Download Git for Windows/Mac/Linux/Solaris

2) Contribute to an existing project

I first learned Git because I wanted to contribute to the Dolphin Emulator. It was a program I used very often to play my favorite games, and was something I wanted to see actively grow. I ended up joining the project's IRC chat room, which was filled with friendly developers willing to lend me a helping hand.

Having a project backed backed by a group of passionate developers really helped me contribute and learn, because I had a well-managed project which set my standards high not just for Git, but for how any team-project should be organized.

In short, find a project you are passionate about on GitHub, setup the code to run locally on your own PC, and don't be afraid to ask for help on any issues that come up along the way.

No contribution is too small, even if it's just changing the wording for a single menu option.

Answer 5

It probably won't fit particulary good for you, as you want the same GUI on every platform, but I want to suggest GitHub Desktop for future readers, who don't have the platform requirement.

GitHub Desktop

GitHub Desktop (source code available on GitHub) is a graphical Git client by GitHub, available for Mac and Windows. It's especially designed to integrate with the hoster GitHub, but should also work with other Git hosters.

I think it's intuitive to use the version-control features of GitHub Desktop, which could be an advantage in your case, as this helps against forgetting commands.

It, however, does not follow the concepts of Git closely - so you will encounter some things that may be intuitive in GitHub Desktop, but appear strange to Git users who know e.g. the command line interface. As Steven Vascellaro points out in his comment, this could be a major downside when wanting to learn Git:

I'm hesitant to recommend GitHub Desktop to a new user trying to learn Git. Similar to using BlueJ for Java, it can be very difficult to transition to a different client after getting used to GitHub Desktop. It obfuscates many important parts of the traditional Git workflow.

---

I would therefore recommend GitHub Desktop to Windows users that want an easy and intuitive way to manage Git (e.g. because they have to use it inside their company) without having to deal much with the sometimes counter-intuitive (looking) concepts of Git.

Answer 6

Oh, you're almost exactly like I was about a year ago. I understood simple version control, and had a good handle on mercurial (thanks to http://hginit.com/). I had even convinced my then company and manager to switch from CVS to mercurial, so handling a DVCS wasn't really the issue. But for whatever reason I could not wrap my head around git. And then I wound up at another position where I was in the role of agitating for an improved version control system, and git was the only other option and I had to learn. And the absolute best resource I found for understanding git at a conceptual level was Git for Ages 4 and Up a roughly 1 and a half hour video that used tinker toys to explain git. That video was what finally started making things click for me. From there playing around in the command line and poking through some of the tutorials others have linked made a lot more sense.

If you have a good understanding of how a linked list data structure works at a low level, I found it helps to think of a git repository like a big linked list of your code at various states. And branches, tags and all the other stuff that goes with it are pointers to those states in the list. Using git is all about manipulating those pointers. But watch that video, it's probably the best "intro to how git works" I've ever come across and doesn't delve too deep into any specifics of the implementation at the time, so even though it's a few years old now, it's still plenty relevant. Lastly, I would recommend if you're already comfortable with the command line that you use the command line while you're learning, and only use GUI tools to show you a visual state of the repository. Understanding the individual commands makes some of the abstractions that the GUI tools use less confusing.

Answer 7

Help students make improvements to a toy website with git & Github

I have taught git and Github basics with this activity from OpenHatch. It was successful for helping students learn git basics: clone, add, commit, push, and pull, as well as Github basics: making an account and repo, submitting an issue, and making a pull request.

In the activity, small groups work to improve a small website housed in a Github repo. The site is also hosted on Github, so they can see changes immediately. Issues are available in the repo for students to claim and then work on. Students really see the difference between running the site locally and seeing the version hosted on Github.

It requires some setup before hand, since students interface with a real Github repo. But it's worth it, since students get to use git in a realistic way (and so they have contextualized knowledge!). Another bonus is that no specific programming language is required, since students can modify text in HTML to complete tasks, or hack some javascript for the most advanced tasks.

Answer 8

I have students follow through the Learn Enough Git to Be Dangerous tutorial, which goes through the basics of setting up a repo, committing, pushing to GitHub, and some simple collaboration.

Git is complicated; my students are usually pretty mystified by it at first. But the nice thing about it, is that once you've learned the basics, you can do things like pushing code to GitHub to share/backup, and it's already a useful tool.

Answer 9

I remember initially struggling with Git.

My main problem (and I'm sure I'm not the only one) was not understanding what the various operations actually did to the DAG, blindly typing obscure commands instead.

I believe that if you think in terms of the DAG, you will be able to master git very quickly, and even make sense of some apparently unintuitive behaviour [*].

I believe that any tools that help think in terms of the DAG would be helpful -- but I don't know firsthand of any GUI that really shines at this.

FallenNode's answer gives you the gem that is LearnGitBranching, which serves this very purpose. I can't recommend it enough.

I'll go against other answers and suggest that the command line is good enough for a beginner, if you take the time to understand what the commands do.

git-cola is a super lightweight GUI, free as in speech, almost certainly shipped by your distro, that you might find useful.

Useful resources:

• https://try.github.io
• https://git-scm.com/book
• http://nvie.com/posts/a-successful-git-branching-model/

---

[*] I'll give just one such example:

git cherry-pick nameofsomebranch

"But", you say, "I thought that you could cherry-pick commits, not branches." Why this works (and what it does!) is left as an exercise ;)

Answer 10

I learned by using StackOverflow and just by being thrown into it. As others have stated using GitHub through an IDE or Desktop version is much easier than the command line. Later on I also found the Codecademy git tutorial

I prefer this method of teaching because its hands on, teaches the user how to use the command line and commands. It also helps with plenty of reference and information as you try these commands in a "live" like environment.

After I learned how to use Git and GitHub I found the above source and it really solidified my knowledge and I hope it does the same for you.

Answer 11

How do I teach git to a teenager

Git is a powerful repository system, yet much of that power is hidden behind simplicity in day-to-day operations.

Like all good teaching, you need to demonstrate the fundamentals and build from there to instil understanding at the appropriate levels.

What can I do to make this journey easier for me?

Practice. The same materials that are suitable for students are also suitable for you to gain an advanced understanding of what Git is doing and how it operates.

What good user interfaces should I adopt?

My preference for interfaces are

• Unix (GNU/Linux) command line
• Unix (GNU/Linux) GUI
• Microsoft's Windows GUI
• Microsoft's command line

So it is important, for me, to have a good command line tool, on my GNU/Linux machine. And important to have a good, and the same, GUI on GNU/Linux and Microsoft Windows.

Without hesitation, you should use the official release client from git-scm.com to meet your requirements. The command line tools and git-gui are included. On Fedora (27) Gnu/Linux, you type sudo dnf install git git-gui, and you are done and ready.

Git-gui is a commit tool (git citool to launch the commit interface tool), I mostly use gitk which is a complete repository browser (for the current branch) and launch git-gui from there should I need it but, I do most of my work from the command line - it is simpler although the tree view in gitk is sometimes helpful to understand what has happened before.

If you want a GUI that is a little less encumbering, I recommend Gitg which is available for Microsoft Windows and Gnu/Linux. It is much less full-blown than gitk and accordingly not as powerful. On Fedora (27) Gnu/Linux you type sudo dnf install gitg and type gitg to launch. On Microsoft Windows, you need to make sure that it is on your path. Gitg lets you browse by branches, tags and sources, as well as manage commits, so it is really quite useful.

My goal

• To use the tool to store the history of my, and pupils, projects.
• To be able to look at past history.
• To be able to revert to past state.
• To merge and resolve conflicts.
• To never think, that live would be easier without it.

The best resources are tested. Grab yourself a copy of Git from the bottom up and Pro Git (both under CC licence).

By the time that you read through those resources, you should have a good grasp of what is involved.

In order to achieve your goals you are going to have to consider two things:

1. Set-up Git config to use a basic text editor for most things, like gedit or notepad. It can be very confusing the first time you try and commit on the command line and you forget to include the commit message or, manage a merge. Oh yeah, if you are using the command line, always remember to include the commit message (in two parts, heading and body, separately each by -m) and --signoff.
2. Decide on your infrastructure. If all students are managing their own repository in their own home folder, then that is fine, that is all that you need but, if you are going to need a Git server, then it is easier to set-up GitHub repositories provided it doesn't matter if student's work is public. Of course, if you have to ask how to set-up a Git server that is a separate (and probably already answered somewhere) ask with a world of possibilities. Setting up a Git server does not need to be overly complicated provided the classroom has the small amount of infrastructure necessary to support it.

Remember, you can always type git commit --help etc. for almost anything.

Good luck!

Answer 12

The first resource I give to students is this one: https://try.github.io/levels/1/challenges/1.

I've heard great things about Github Patchwork - a mentored workshop for beginners. You may want to look into this for your students if that makes sense for your situation. At the bottom of the Patchwork site, you will find some additional guides and resources.

Answer 13

There are a few cornerstones to master to establish a good foundation for understanding and using Git.

Purpose

The purpose of git is to control the history and versions of text files. There are two main problems, cooperative writing and controlling edits. E-mailing zip files is terribly inefficient. Edit/Undo is quite limited (no branching) in Microsoft Word or a typical editor - but with Git you get to create different versions as snapshots in time, edit features independently, rollback edits, etc.

Inner Workings

This need not be excessive. The fundamental building block here is the text file 'diff'. Then it is understanding a commit is just a node on a tree where the nodes are connected via diff's. Branches just point towards a commit. This is simple model to understand git.

Visualization

When working with git, you can get lost. For reassurance on what actions to take, a quick look at the history is incredibly helpful. This need not necessitate a GUI, in fact I recommend terminal. Add these aliases to your ~/.gitconfig for help visualizing the source.

[alias]
    lol = log --graph --decorate --pretty=oneline --abbrev-commit
    lola = log --graph --decorate --pretty=oneline --abbrev-commit --all

By fostering these fundamentals, the only thing between novice and expert is experience.

Answer 14

I learned Git several years ago by reading Pro Git. I found that the first three chapters contain about 90% of what I use on typical projects. The rest is just gravy if you want to dig into more details. All of its examples are command-line and use Linux conventions. Since the Windows version of Git comes with Git Bash, this is not a problem. Most documentation will use the same terminology as the command-line tools, so learning them is crucial. Learning the command-line also helps in understanding GUI tools as well.

Answer 15

Git is a horror show of a user interface built on a fairly clean, simple, purely functional data store. I liked Ben Lynn's "git magic" tutorial, but I'm really here to urge you to try the Magit user interface built in GNU Emacs. It offers these key advantages:

• You get a screen that presents a visualization of the states of your working tree, your repository, and related remote repositories. This means you can see changes as they happen, which helps you learn and understand.

• You get prompts for the keystrokes. This means you don't have to memorize the huge command set or trawl through the voluminous man pages.

• You work with keystrokes, just as you would at the command line. This means you don't have a mouse slowing you down.

• You will quickly learn to do common operations fast.

The learning curve is still steep. But seeing things change as you chance them is huge.

If you don't already use Emacs, you won't realize all these advantages. But it might still be worth a try.

Answer 16

What worked for me...

was working with Git.

I hadn’t used any kind of version-control software when I started college (I was a teenager!). I had mostly been using MonoDevelop to program in C#, but boy were those just not interesting or good programs.

I had a little experience with the command line; I could ls and cd and the like, but nothing like the beautiful pipelines I wield today.

I got started using Git, as a freshman in CS, because I wanted to use GitHub pages and Jekyll to make a blog.

I followed some simple CLI instructions to get up and running. (I’ll link back today’s equivalent if I find it later.) Because it was just me working, I didn’t have to learn much to use Git like this.

About this time, I took a detour and start upping my command-line game, learning vim and bash, hosting my Dotfiles on GitHub (the early history is frankly embarrassing, but it’s nice to know how far I’ve come).

But I was also working on class projects then. I started keeping those in Git, even just locally. Until one day I decided to put my unit tests for an assignment on GitHub to share with the class. Suddenly I had PRs and issues and I had to learn how to branch better and deal with merge conflicts, among other things to use Git effectively to collaborate.

That was 2016-2017.

That was before I had a good grasp on git’s internal object database, its beautiful graph model, its immutability, what a rebase was, how to use submodules and worktrees, or any of my other day-to-day git tasks. I now use all of these things pretty regularly.

Recap

So, in a few months of just working on things I cared about, I had learnt enough to be dangerous.

A few months later (especially after reading this excellent book—several times), I was a bit of a wizard.

Now, several years later, I’m preparing to give an intro workshop to beginners at Pearl Hacks. Unfortunately, since I don’t have time to cover the command line too, we’ll be using GitHub Desktop, but the journey will be more or less the same. We’ll cover the basics, and get them going on something they care about. And I’ll give them resources for when they’re ready to dive deeper.

Passion is such a great teacher.

Answer 17

It was @Torek over at stackoverflow who made a comment which I believe is the nub of the problem. It went something like

The git implementers tend to emphasize implementation over policy

It is the corollary to this that is hitting you and your students viz

git is badly documented not in the sense that documentation is absent but in the sense that

• chockful of too many details
• badly ordered
• abstractions either absent
• Or leaky
• Poor/absent precis/for-dummies docs — you never know when you've stumbled onto an internal detail or poweruser tool
• All plastered over with endless fanboyism

Case in point

Lineendings

History Capsule

In the beginning Linus Torvalds made cavalier comments about the fact that git only dealt with data, ie bytes, and he could not care less about lf vs crlf questions. As hindsight showed this was terribly wrong, though it worked at the time, for the wrong reasons — viz all the kernel devs sharing code were making the same assumptions — source code files should use lf.

As the net widened to Microsoft's Windows users it became clear that this was an untenable assumption; "Cured" by the hack called autocrlf.

When git comprehensively knocked out all the other versioning competition the clunkyness of the autocrlf-hack and its epidemic consequences emerged. Later "Cured" by gitattributes replacing autocrlf.

No doubt gitattributes is a vast improvement over autocrlf, but (in by humble opinion) not nearly enough.

Following I'll try and elaborate what's wrong.

This answer of mine is at a more practical level: with the current git feature-set how to work round the issues.

For here I'd like to take a more hi-level view

Philosophical gaffes and Pedagogical consequences

A binary file is a sequence of bytes

A text file is different. It's a sequence of lines each of which is a sequence of chars

That one can be serialized as the other is an irrelevancy. The relevant point is that as data-structures they are different.

And so if I ask you

Do you work on an lf or a crlf OS?

The most reasonable (and polite) answer you can respond with is

That's none of your business

In the same way that

What is the color of your shirt (or skin)?

is answered.

JFTR the number of possibilities is endlessly larger than {lf, crlf, cr}. Consider pasting a text file into a code block here on stackexchange. It's entirely conceivable that all lineendings transmogrify into <br/>s and actually disappear!

And in all these cases questions about this are best handled with

• not your business
• not relevant
• not even wrong
• etc

Instead...

Git does it wrong all over

• Messages such as lf will be replaced by crlf
• Documentation that is clunky and unabstract eg git stores text as lf. Why is this anyone's business (other than git plumbing implementer's?) Following from
• Abstractions that leak all over. Eg discussions in terms of lf/crlf files rather than nix-text Vs windows-text. All resulting in...
• Erroring out too late at the wrong time and place. Eg safecrlf true only by intention not by default.

Suggestions

If you want a lightweight graduated introduction to version control you can consider

• RCS (*nix only)

• Fossil

• etc

Not suggestions I make too willingly : git has comprehensively won the version-war and avoiding it is just postponing.

So if we realize that we must willy-nilly bite the bullet, the other answers here do a better job than I can.

All I'll say is not too constructive: the docs are the problem more than the design. Concentrate there.

---

Added later

I just discovered the hilarious fact that the old message LF will be replaced by CRLF is now flipped to CRLF will be replaced by LF for the same problem!!.

Does this mean the git-devs themselves are confused? Not at all — the surrounding text is suitably changed in older and newer version. What it does mean (IMHO) is that the level of abstraction for communications between the git system and vanilla users is quite impaired. It should not be talking verbs — replaced — but nouns — Windows/*nix files... as vi, emacs and any decent editor does.

Answer 18

When I was in my final year of university I threw together a quick Git cheat sheet for some fellow students I was working with who were struggling with basic use of Git. The cheatsheet is available as a bitbucket snippet.

Other than that Atlassian has a freely available git gui client for Mac and Windows called sourcetree, I've found it pretty intuitive to learn and use. Following on from that there's another tool called SmartGit which is freely available for non-commercial use and runs on all major operating systems (Win, Mac, Linux). This is an incredibly powerful git tool which gives you access to most of the functionality that Git offers, however it is a proprietary piece of software which you have to pay for if you want to use it for commercial purposes.

I get by using the console commands for 99% of my work, the only time I break out a GUI is when I mess up and need to roll back changes, or for doing other complex operations.

Answer 19

I was just watching https://media.libreplanet.org/u/libreplanet/m/a-free-software-portfolio-the-importance-of-free-software-in-computer-science/

The presenter talk about teachingopensource.org, and how they have put together educational materials for Free and Open Source software. He says that the material is put together by teachers. see teachingopensource.org git search

---

I got this link from reddit https://learngitbranching.js.org/ maybe it will be of use. But I doubt that it will make git easy to use.

---

Note: I have not tried these yet.

Answer 20

I'm late to the conversation, but wanted to offer...

GUI application: GitKraken

Several people have mentioned other GUI applications for git. I had explored a lot of them when I decided to integrate basic git in my introductory (college) courses and found GitKraken to be far better than its alternatives, predominantly because:

• It is free-of-charge download, and doesn't require you to use one particular IDE
• It is cross-platform AND looks the same on MacOS/Windows/*nix
• It has a better interface that is easier to learn

Tutorial: Learn Git Branching from js.org

I also echo the recommendations for going through (at least the "Main" modules) from the Learn Git Branching tutorial. It is interactive and has been so effective that I now assign it as homework for my Software Engineering students to learn some of the more advanced.

Answer 21

I'll start by echoing the fantastic resource in FallenNode's answer (https://learngitbranching.js.org/) which visualizes git very well and game-ifies the learning experience.

I also recommend: http://git-school.github.io/visualizing-git/

It's an open sandbox tool for visualizing various sequences of git commands, including situations with remote repositories.

I'll add one more tutorial resource that is not visual, but pretty good for learning the basics of remote git work: https://github.com/jlord/git-it-electron

Download installation binaries at: https://github.com/jlord/git-it-electron/releases

Answer 22

Oh My Git! is a free game that teaches Git. It explains:

1. Commits
2. Branches
3. Merging and conflict resolution
4. Remotes repositories
5. Restoring files
6. Bisect
7. Stashing
8. Tags

It includes a nice graph display of all commits, branches, tags, etc. and HEAD. Git commands can either be entered into a built-in terminal or by "playing cards": There is e.g. a card with "git checkout" and a short description written on it, which you can drag onto a commit or a branch name to checkout.

I haven't tried it with Git beginners yet, but I myself quite liked playing it and could imagine that especially the cards feature could be helpful to students.

Answer 23

First up, I would strongly recommend staying away from Git GUI tools. Whether you a student (for whom everything is new) or someone who has worked but is new to git itself, command line should be where you should start.

Second, Till about 3 years ago, I did not know anything about git. Here is how I learnt.

1. Visited Github (and later Bitbucket, which is more appealing to my students because most of its features are free) and signed up for an account.
2. Created a new project. Right away, they would give you straightforward instructions on what to do next from the command line.
3. (optional step) if git is not installed, use any of the hundreds of videos or blogs on how to install and get it configured.

For instance, when I create a new project on bitbucket, and I get these concise instructions.

I have an existing project

Step 1: Switch to your repository's directory

cd /path/to/your/repo

Step 2: Connect your existing repository to Bitbucket

git remote add origin https://Jay_sn@bitbucket.org/Jay_sn/demo_repo_1.git
git push -u origin master

I'm starting from scratch

git clone https://Jay_sn@bitbucket.org/Jay_sn/demo_repo_1.git
cd demo_repo_1
echo "# My project's README" >> README.md
git add README.md
git commit -m "Initial commit"
git push -u origin master

It really cannot get simpler than that.

Answer 24

How I have personally used git, successfully.

I mostly use mercurial. It is like git. It does much the same thing, but is much easier to use. It has a nice command line, and a nice GUI (tortoise hg).

Mercurial has a git plug-in, that allows it to work with git repositories. If there is this git repository, that you want to work on, then you do a clone in mercurial, and now you have it in mercurial (just as you could have done a clone in git). You then work in mercurial, and can push/pull changes back to the upstream repository, or to a friends repository (just as you could have done in git). The only difference is the interface is easier to use.

Disadvantages

When you clone a git repository, you end up with a git repository and a mercurial repository on you local drive. Thus the size of the local repository is roughly double.

Mercurial is not efficient at renames and moves. It does a copy and delete. This may have a fix sometime.

---

A note on mercurial and git UI

• The git UI is very low level, it is a thin layer over the API.
• The git GUIs that I have used are a thin vale over this API or a UI. It does not help. It does display all of the commands, in a nice menu, but you will still be at a loss to decide which command is the right one.
• The mercurial UI is well thought out, there is mostly a one to one mapping between commands and concepts. It is simple and follows the Unix way, each command does one thing well.
• The mercurial GUI (tortoisehg), integrated with the file-manager, provides good visuals of the repository, and gives access to tools without having to remember commands (so good for beginners, for operations you do rarely, and for operations that need better visual display).