# How do I teach git to a teenager

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 never think, that live would be easier without it.

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.

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.

• I second this resource. I think it's miles above in quality compared to any other git tutorial. Other tutorials take a cookbook-like approach and teach git commands as a series of things to be memorized, or talk about git model in a fairly abstract and hard-to-grasp way. This tutorial does focus on git's underlying model, and does a great job of helping you see what's inherently possible and not possible with git (even if you might not remember the exact commands to do something). – Michael0x2a Jul 24 '17 at 18:17
• I will check out this tutorial. Thanks! Also, welcome to Computer Science Educators! I hope we hear more from you in the future. – Ben I. Jul 24 '17 at 18:45
• I fortunately stumpled upon this Q on the hot network questions tab. I was looking for an easy to understand Tutorial the other day, and just clicked trough it. I Went from being hopelessly confused to actually understanding most of the stuff behind the scenes over the course of two hours. And it was even fun! Absolutely brilliant! – antipattern Jul 25 '17 at 10:44
• +1, I found that tutorial to be helpful. But it makes you operate on artificial commits. Ungit[1] displays a similar graph of commits, but is a regular Git frontend. Your students can use it for their assignments. If you insist on teaching them CLI first, they can use Ungit to visualize the results of their CLI commands. [1] github.com/FredrikNoren/ungit – user31389 Jul 25 '17 at 12:20
• I understand the internal state. It is the UI that I struggle with. – ctrl-alt-delor Mar 19 '19 at 0:20

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.

• Nice answer. OP, notice that a "git server" is just another remote to git. This means, for example, that you can use remotes also for local backups, et cetera. – Tobia Tesan Jul 24 '17 at 16:49
• I like this answer a lot too. I spent a -long- time just doing git commit/push on my own private repositories. It was just nice to have backup files. Eventually you say "oh, wouldn't it be nice if Git did that" and you will probably 1) find how on stackoverflow and 2) see how many others viewed or upvoted canonical questions. – user2206 Jul 24 '17 at 22:11

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. Eclipse, for example, uses EGit for Git integration. The JetBrains IDEs also provide Git support. The text editor Atom can be extended with plugins (e.g. Git+) to 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.

• The only thing I'd add to this is would be that command line is almost imperative for most things above basic usage. For example, git stash [pop] and git reset HEAD~[n] (Note: these can be very dangerous if not used properly. Beware) are things that I've found extremely useful, but have yet to find in any plugin/IDE. Whether that's my inability to find the functionality, or the plugin not having it, I don't know, but the OP seemed to express interest in more comprehensive functionality. – Daevin Jul 24 '17 at 16:17
• @Daevin This is a good point. I know that at least the JetBrains IDEs usually provide access to a terminal, so you could type those commands there. -- As a sidenote: I think EGit even has the commands you're talking about as a built-in: Stashing should be possible with "Team > Stashes > ...", resetting using "Replace with > ...". But I nevertheless get your point ;) – TuringTux Jul 24 '17 at 16:47
• ah, gotcha. Most of my experience comes from the Visual Studio plugin for Git, Visual Studio's Team Explorer, and the GitHub desktop client, which are quite limited in their implementation of commands. I've used JetBrains' and Android Studio's git integration, though it was a couple years ago, and I found it to be lacking as well. But, as you said, most of these have the ability to open the command line to your local repo, so I guess the point is moot, as long as you know the commands :P – Daevin Jul 24 '17 at 18:41
• Visual Studio 2017 also has Git integration called the "Team Explorer" and is very easy to use, particularly with hard resets (which I have used incorrectly far too many times x_x). – kem Jul 24 '17 at 22:28
• @Daevin Just so you know, IntelliJ IDEs support stash [pop], reset HEAD~[n] (via selecting it in the log), and even interactive rebase as part of their in-IDE Git integration. The only time I go to the command line anymore is for less-well-written build tools that need to be run in a subdirectory of my project. – CAD97 Jul 25 '17 at 8:19

# 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.

# 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.

• Seconding Git GUI and in particular gitk (under repository->visualize all branch history) for visualizing the current state of affairs. – Sumyrda - remember Monica Jul 25 '17 at 13:30
• Upvoted. Even if you generally prefer command-line once you know what you are doing (as all True Developers should), the GUI is great for learning the capabilities and expected workflow of the system. This is precisely how I learned, with the exception that instead of #2 I used it on a small project of my own to get my feet under me. That also meant I wasn't screwing up anybody else when I made the first few inevitable noob mistakes. Of course using someone else's IDE (as suggested in another answer) is not as helpful because those weren't designed around Git like Git GUI was. – T.E.D. Jul 25 '17 at 14:34

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.

• gitkraken is a great cross platform graphical git GUI which I can recommend. – Daniel Vestøl Jul 24 '17 at 17:23
• Does a GUI make git easy to learn, or just easier to use? Most of the developers I've worked with who used a GUI for git still didn't really understand git. They just knew where to click to make something happen, and if anything went wrong, they were lost. – Wayne Conrad Jul 24 '17 at 19:06
• @WayneConrad Depends on the GUI, I think. For GitHub Desktop, I'd say it probably just makes it easier to use, however, it at least helps against forgetting commands. Other answers here provide GUIs that are better for learning, I think. – TuringTux Jul 24 '17 at 19:08
• 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. – Stevoisiak Jul 24 '17 at 20:31
• @StevenVascellaro Good point - you pointed out something I'd had partially in mind when writing the answer but couldn't really express well. If you want to, you could edit in a paragraph with the contents of your comment. – TuringTux Jul 25 '17 at 5:51

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.

• Welcome to Computer Science Educators! This is a very good answer. I hope we'll be seeing more answers and questions from you. – ItamarG3 Jul 25 '17 at 13:05
• I just watched the video. I realised that it is not just me. The internals are easy, the interface is not. I also learnt that git now gives useful help messages (it would be better if it was easier to use, but this is a start). I will probably stick with mercurial for now (though mercurial does not handle renames, efficiently). – ctrl-alt-delor Jul 26 '17 at 12:21
• @richard, yeah the git interface can be difficult from time to time, but it's worth learning. Having used mercurial for the past few years, and having spent the last year or so getting deeply familiar with git, I'm finally beginning to understand all the hubub. Mercurial is a fine tool and I still use it, it gives almost all the benefits of using git while being a simpler model to understand and there's enough plugins I bet it can replicate 98% of the git feature set. But once I got the git model, it started to feel much more natural as a developer, and I've started moving to git exclusively – moneyt Jul 26 '17 at 14:46

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.

## 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.

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:

[*] 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 ;)

• While I won't argue that git isn't unintuitive at times, cherry-pick branchname isn't really one of them IMO. This is actually something I discovered neither by accident nor search, but by reasoning: “so I want to CP the last commit from branch B. Hm, I could parse out the commit ID, wait, how do you do that again? Oh never mind, I'll just git log B and copy&paste that commit ID... but wait, what if I simply write git cherry-pick B in one command?” – leftaroundabout Jul 24 '17 at 21:24
• I would say that the interface to git isn't unintuitive sometimes, but I want it to not be unintuitive all of the time. – ctrl-alt-delor Jul 24 '17 at 21:29
• When I was first learning it seemed like everything was DAG-this and DAG-that and I thought "Yes, I get it it's using a directed acyclic graph for storage; now TELL ME HOW TO USE GIT.". The some day it clicked and I thought: "Oh, it's a directed acyclic graph! Everything is so simple now." – Odalrick Jul 25 '17 at 14:17
• ...which is again why you should start with Git GUI, which gives you a nice graphical picture of the DAG. – T.E.D. Jul 25 '17 at 14:38

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.

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.

• Can you expand on why this tutorial is better than any other? Without any explanation, this is a link only answer, which would be useless if the link dies. – thesecretmaster Aug 20 '17 at 20:09

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.

• Welcome to Computer Science Educators! This is a very nice answer. I hope we'll be getting more answers and questions from you :) – ItamarG3 Jul 24 '17 at 21:08
• Comments are not for extended discussion; this conversation has been moved to chat. – thesecretmaster Jul 25 '17 at 0:47

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.

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.

# 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!

• Welcome to Computer Science Educators! This is a wonderfully detailed answer! I hope we'll see more contributions from you in the future. – ItamarG3 Mar 12 '18 at 12:20

## 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.

• The opportunity to write this answer means I need to go rewrite the intro of my workshop. Thank you. – D. Ben Knoble Jan 18 at 14:14
• I am now wondering if it is not the teenager that will find it hardest. May be it is because of my experience with tools that are easier to use, that I am resisting the change. And git has the potential to be easy to use, it is just that no-one has made a good command-line tool for it. Or a tortoise for it. (hg is easier to use, but its internal model is not quite as good. SVN is easier to use, but is not decentralised ). Maybe I need to wait for a distributed system, maybe it will also be easy to use. Or maybe one summer, I will make a UI. – ctrl-alt-delor Jan 18 at 15:15
• @ctrl-alt-delor understandable—i have the same frustration with tools i find hard to use. Ironically, git is such a part of my workflow that it now feels easy to use. But ive added lots of shortcuts (aliases and scripts) that fit my personal interface for git, plus hub for interacting with github. I suppose it also depends on how you rate “easy”—i never used SVN, but I’ve read horror stories about using it for merges? – D. Ben Knoble Jan 18 at 15:18
• Easy for me is low effort. For a teenager it would be easy to learn, no surprises. Yes SVN used not to track merges. It made it hard to re-merge a branch. You had to do a lot of manual stuff to tell it the newest-common-ancestor. I hear this is now fixed (I have not used it (in a team, with merges) since this fix). With HG and SVN commands do one thing (if no --option given), and are split into 3 parts (examples for hg): access remote (pull, push), write to local repo (commit, merge), mutate working copy (update), then extensions with safety catches: mutate local repo (strip). – ctrl-alt-delor Jan 18 at 15:31
• @ctrl-alt-delor I've just read about Tower (recently added to the GitHub student pack). I haven't investigated their pricing options, but if it really does what they say, it would be an alternative interface to consider. – D. Ben Knoble Jan 21 at 2:49

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
• 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

In the same way that

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

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!

# 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

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.

• Upvoted because I learned something, but all of the sentence fragments make this answer quite difficult to follow. – Ben I. Jan 21 at 13:24
• I fixed some grammar, but it still needs proof reading and fixing. – ctrl-alt-delor Jan 22 at 8:00
• While you perfectly identified the problem in the first section (+1), do you have a solution (other than use a different system)? – ctrl-alt-delor Jan 22 at 8:01
• The line ending thing should be an option, and one check-out and diff. I have had data destroyed with other revision control systems, transforming on check-in. And cr/lf is a failure to abstract away the hardware (it was done to support printers. Do they still work that way). – ctrl-alt-delor Jan 22 at 10:10
• @ctrl-alt-delor Many things to work on in this q. I've not yet managed to satisfactorily make my central point re line-endings. There is the legitimate issue of presentation. And the larger q about what I would suggest in the circumstances. Crlf etc is only really an analogical side show to indicate excessive detail obscurling central abstractions – Rusi Jan 22 at 13:17

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.

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.

• Interesting, but no use for me (number 6) as it is a proprietary program (Not Free). – ctrl-alt-delor Mar 22 '19 at 19:54
• Ah, yes, I'd overlooked your restriction to only considering FOSS. That's really going to limit your options and honestly, you're probably best just learning command-line git. For what it's worth, I've taught all my intro classes (both CS1 and a pseudo-CS0.5) with very basic git. They learn to fork (on GitHub) my work, clone their forks so they can edit code locally, stage and commit new revisions, and push their work back up to their forks. It usually takes a little struggling at first, but most students have it down within a few assignments. – Kevin Buffardi Mar 22 '19 at 20:08
• I do command-line and Gui mercurial (hg). It is much easier, but a shame that its internals are not so beautiful. Hopefully the next gen revision-control system (distributed), will be beautiful on the inside and the outside. – ctrl-alt-delor Mar 22 '19 at 20:11

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

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.

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
git commit -m "Initial commit"
git push -u origin master


It really cannot get simpler than that.

• – thesecretmaster Aug 20 '17 at 18:47
• I read through all the answers and realised that what helped me 2 years ago, the simple stuff, wasn't there. I have used this technique in live training sessions and it has helped hundreds of students. When it comes to training and learning things, I believe that there is one right method. there are many methods, and the more the merrier. The post is about making GIT easy. I shared what made it easy for my students :) – Jay Aug 21 '17 at 4:01
• (not able to edit my comment so posting this here) in the above comment, 'I believe that there is one right method'. I meant, "I believe that there is no one right method" :) – Jay Aug 21 '17 at 5:31
• Yes, it's great that you are willing to share your experiance, but you still havn't explained how your experiance is any different from the other answer I linked. – thesecretmaster Aug 21 '17 at 11:14

# 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.