<p>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 <a href="https://bitbucket.org/snippets/robb-gosset/xKzKa/git-cheat-sheet" rel="nofollow noreferrer">bitbucket snippet</a>.</p>

<p>Other than that Atlassian has a freely available git gui client for Mac and Windows called <a href="https://www.sourcetreeapp.com/" rel="nofollow noreferrer">sourcetree</a>, I've found it pretty intuitive to learn and use. Following on from that there's another tool called <a href="http://www.syntevo.com/smartgit/" rel="nofollow noreferrer">SmartGit</a> 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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-07-24T16:24:00.380Z
2017-07-24T21:14:07.290Z
2017-07-24T21:14:07.290Z
RobbG
<p>I was just watching <a href="https://media.libreplanet.org/u/libreplanet/m/a-free-software-portfolio-the-importance-of-free-software-in-computer-science/" rel="nofollow noreferrer">https://media.libreplanet.org/u/libreplanet/m/a-free-software-portfolio-the-importance-of-free-software-in-computer-science/</a> </p>

<p>The presenter talk about  <a href="http://teachingopensource.org" rel="nofollow noreferrer">teachingopensource.org</a>, 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 <a href="http://teachingopensource.org/?s=git" rel="nofollow noreferrer">teachingopensource.org git search</a></p>

<hr>

<p>I got this link from reddit <a href="https://learngitbranching.js.org/" rel="nofollow noreferrer">https://learngitbranching.js.org/</a> maybe it will be of use. But I doubt that it will make git easy to use.</p>

<hr>

<p>Note: I have not tried these yet.</p>

CC BY-SA 4.0
2017-10-14T18:24:35.027Z
2020-04-21T07:12:41.527Z
2020-04-21T07:12:41.527Z
ctrl-alt-delor
<p>I'll start by echoing the fantastic resource in FallenNode's answer (<a href="https://learngitbranching.js.org/" rel="nofollow noreferrer">https://learngitbranching.js.org/</a>) which visualizes git very well and game-ifies the learning experience.</p>

<p>I also recommend: <a href="http://git-school.github.io/visualizing-git/" rel="nofollow noreferrer">http://git-school.github.io/visualizing-git/</a></p>

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

<p>I'll add one more tutorial resource that is not visual, but pretty good for learning the basics of remote git work: <a href="https://github.com/jlord/git-it-electron" rel="nofollow noreferrer">https://github.com/jlord/git-it-electron</a></p>

<p>Download installation binaries at: <a href="https://github.com/jlord/git-it-electron/releases" rel="nofollow noreferrer">https://github.com/jlord/git-it-electron/releases</a></p>

CC BY-SA 4.0
2020-02-10T15:46:38.443Z
2020-02-10T15:46:38.443Z
Matthew W.
<p><a href="https://ohmygit.org/" rel="nofollow noreferrer">Oh My Git!</a> is a free game that teaches Git.  It explains:</p>
<ol>
<li>Commits</li>
<li>Branches</li>
<li>Merging and conflict resolution</li>
<li>Remotes repositories</li>
<li>Restoring files</li>
<li>Bisect</li>
<li>Stashing</li>
<li>Tags</li>
</ol>
<p>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 &quot;playing cards&quot;: There is e.g. a card with &quot;git checkout&quot; and a short description written on it, which you can drag onto a commit or a branch name to checkout.</p>
<p>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.</p>

CC BY-SA 4.0
2022-06-20T18:21:03.070Z
I will try soon.
ctrl-alt-delor
CC BY-SA 4.0
2022-06-20T18:49:26.270Z
Nice, please feel free to share your experience here afterwards. I am excited to hear how it works out :)
TuringTux
CC BY-SA 4.0
2022-06-18T18:02:25.337Z
2022-06-18T18:02:25.337Z
TuringTux
<p>I'm late to the conversation, but wanted to offer...</p>

<p><strong>GUI application: GitKraken</strong></p>

<p>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 <a href="https://www.gitkraken.com/" rel="nofollow noreferrer">GitKraken</a> to be far better than its alternatives, predominantly because:</p>

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

<p><strong>Tutorial: Learn Git Branching from js.org</strong></p>

<p>I also echo the recommendations for going through (at least the "Main" modules) from the <a href="https://learngitbranching.js.org/" rel="nofollow noreferrer">Learn Git Branching tutorial</a>. 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.</p>

CC BY-SA 4.0
2019-03-22T19:54:12.483Z
Interesting, but no use for me (number 6) as it is a proprietary program (Not [Free](https://www.gnu.org/philosophy/free-sw.en.html)).
ctrl-alt-delor
CC BY-SA 4.0
2019-03-22T20:08:08.257Z
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
CC BY-SA 4.0
2019-03-22T20:11:41.677Z
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
CC BY-SA 4.0
2019-03-22T19:31:27.203Z
2019-03-22T20:06:28.767Z
2019-03-22T20:06:28.767Z
Kevin Buffardi
<h1>How I have personally used git, successfully.</h1>
<p>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).</p>
<p>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.</p>
<h2>Disadvantages</h2>
<p>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.</p>
<p>Mercurial is not efficient at renames and moves. It does a copy and delete. This may have a fix sometime.</p>
<hr />
<h1>A note on mercurial and git UI</h1>
<ul>
<li>The git UI is very low level, it is a thin layer over the API.</li>
<li>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.</li>
<li>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.</li>
<li>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).</li>
</ul>

CC BY-SA 3.0
2018-01-03T16:54:49.777Z
Can the person that down voted. please give feedback. Formative feedback (this is how you can do better, this is where you are wrong) is of value, Sumative feedback (grades) is not.
ctrl-alt-delor
CC BY-SA 3.0
2017-11-02T11:46:09.567Z
2017-11-24T17:56:56.023Z
2020-06-18T08:36:57.023Z
ctrl-alt-delor
<p>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. </p>

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

<ol>
<li>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.</li>
<li>Created a new project. Right away, they would give you straightforward instructions on what to do next from the command line. </li>
<li>(optional step) if git is not installed, use any of the hundreds of videos or blogs on how to install and get it configured.</li>
</ol>

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

<p><em>I have an existing project</em></p>

<p>Step 1: Switch to your repository's directory</p>

<pre><code>cd /path/to/your/repo
</code></pre>

<p>Step 2: Connect your existing repository to Bitbucket</p>

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

<p><em>I'm starting from scratch</em></p>

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

<p>It really cannot get simpler than that. </p>

CC BY-SA 3.0
2017-08-20T18:47:46.743Z
What does this answer add to [this other answer about using the command line instead of a GUI and mentioning online git resources such as GitHub, GitLab, BitBucket, etc.](https://cseducators.stackexchange.com/a/2912/58)?
thesecretmaster
CC BY-SA 3.0
2017-08-21T04:01:11.457Z
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
CC BY-SA 3.0
2017-08-21T05:31:50.380Z
(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
CC BY-SA 3.0
2017-08-21T11:14:02.153Z
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
CC BY-SA 3.0
2017-08-21T11:43:19.817Z
I am sorry man, but I really have nothing else to add. I thought this forum was about sharing experiences. I checked all the other answers. I believe things can be a little more succinct. If my answer is so bad (or spam, accidentally), I am sure it should and will get down voted into oblivion, and I will be schooled. 

However, after your comments, I ran this page and all the answers including mine with my own students. So, I will stick with my answer and I do believe it adds some value to the discussion here.
Jay
CC BY-SA 3.0
2017-08-21T11:56:28.800Z
Let's continue this conversation [in chat](http://chat.stackexchange.com/rooms/64170/discussion-on-answer-by-jay-how-to-make-git-easy-to-learn).
thesecretmaster
CC BY-SA 3.0
2017-11-02T22:36:32.810Z
for a local project you need to do a `git init`.
ctrl-alt-delor
CC BY-SA 3.0
2017-08-20T16:11:45.497Z
2017-11-02T22:37:48.343Z
2017-11-02T22:37:48.343Z
Jay
<p>I highly recommend this tutorial: <a href="http://learngitbranching.js.org/" rel="noreferrer">http://learngitbranching.js.org/</a></p>

<p>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.</p>

CC BY-SA 4.0
2019-03-19T00:20:02.623Z
I understand the internal state. It is the UI that I struggle with.
ctrl-alt-delor
CC BY-SA 4.0
2019-03-20T03:46:23.570Z
If you're looking for a git UI there are many to choose from. I recommend [GitKraken](https://www.gitkraken.com/git-client). 

A full list can be found at [https://git-scm.com/download/gui/windows](https://git-scm.com/download/gui/windows).
FallenNode
CC BY-SA 4.0
2020-01-23T14:10:53.623Z
Relatedly, http://git-school.github.io/visualizing-git/ has a great visualizer playground. There are a few pre-set examples too.
Matthew W.
CC BY-SA 3.0
2017-07-24T18:17:41.647Z
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
CC BY-SA 3.0
2017-07-24T18:45:40.143Z
I will check out this tutorial. Thanks! Also, welcome to [cseducators.se]! I hope we hear more from you in the future.
Ben I.
CC BY-SA 3.0
2017-07-25T10:44:53.687Z
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
CC BY-SA 3.0
2017-07-25T12:20:46.250Z
+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] https://github.com/FredrikNoren/ungit
user31389
CC BY-SA 3.0
2017-07-24T18:12:06.670Z
2017-07-24T18:12:06.670Z
FallenNode
<p>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.</p>

<h2>GitHub Desktop</h2>

<p><a href="https://desktop.github.com/" rel="nofollow noreferrer">GitHub Desktop</a> (<a href="https://github.com/desktop/desktop" rel="nofollow noreferrer">source code available on GitHub</a>) 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.</p>

<p>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.</p>

<p>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 <a href="https://cseducators.stackexchange.com/users/1091/steven-vascellaro">Steven Vascellaro</a> points out in <a href="https://cseducators.stackexchange.com/questions/2897/how-to-make-git-easy-to-learn#comment5973_2901">his comment</a>, this could be a major downside when wanting to learn Git:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<hr>

<p>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.</p>

CC BY-SA 3.0
2017-07-24T17:23:56.170Z
gitkraken is a great cross platform graphical git GUI which I can recommend.
Daniel Vestøl
CC BY-SA 3.0
2017-07-24T18:22:30.877Z
@DanielVestøl Nice idea! Why don't you write an answer suggesting GitKraken as client? It's not Open Source, so it doesn't fullfill OP's requirements in this point but neither does mine here - I'd love to hear from you ;)
TuringTux
CC BY-SA 3.0
2017-07-24T19:06:32.247Z
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
CC BY-SA 3.0
2017-07-24T19:08:57.930Z
@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
CC BY-SA 3.0
2017-07-24T20:31:02.110Z
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
CC BY-SA 3.0
2017-07-25T05:51:46.813Z
@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
CC BY-SA 3.0
2017-07-25T10:21:03.203Z
@TuringTux I'm not entirely sure where I'd fit it in.
Stevoisiak
CC BY-SA 3.0
2017-07-25T10:41:32.010Z
@StevenVascellaro Probably below "[...] but appear strange to Git users who know e.g. the command line interface.". I think it would fit there nicely.
TuringTux
CC BY-SA 3.0
2017-07-25T10:56:18.397Z
@TuringTux Feel free to add it in how you see fit. If you want to, just hyperlink back to the comment
Stevoisiak
CC BY-SA 4.0
2022-08-09T07:44:04.293Z
If the goal is to be able to use most basic features of Git e.g. branches, commits, etc., then using a GUI is great precisely because you don't have to learn git and it's intuitive. As many points out, although the question asks about *learning Git*, we all know that at the end of the day, most of us just mindlessly copy-paste the commands, often without knowing the deeper details. In such cases, it doesn't make sense to avoid using a GUI like GitHub Desktop. Personally, I would suggest teaching basic Git and then showing how to do the same with GitHub Desktop or another GUI for comparison.
Simply Beautiful Art
CC BY-SA 3.0
2017-07-24T11:02:03.860Z
2017-07-25T11:10:57.123Z
2017-07-25T11:10:57.123Z
TuringTux
<p>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 <em>awesome</em>.</p>

<p>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 <a href="https://try.github.io/levels/1/challenges/1" rel="noreferrer">tutorial</a>. Here's another, more comprehensive <a href="https://www.atlassian.com/git/tutorials" rel="noreferrer">one</a>.</p>

<p><strong>Windows</strong></p>

<p>You can download a Git client for Windows here: <a href="https://git-scm.com/" rel="noreferrer">https://git-scm.com/</a> . This will give you a light bash terminal that you're already familiar with.</p>

<p><strong>Mac</strong></p>

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

<p><strong>Gnu/Linux</strong></p>

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

<p><strong>What's really going on?</strong></p>

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

<p><strong>Connecting to GitHub, Bitbucket, etc.</strong></p>

<p>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 <em>free</em> accounts at <a href="https://github.com/" rel="noreferrer">GitHub</a>, <a href="https://bitbucket.org/product" rel="noreferrer">Bitbucket</a>, or <a href="https://gitlab.com/users/sign_in" rel="noreferrer">GitLab</a>.</p>

CC BY-SA 3.0
2017-07-24T16:49:18.977Z
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
CC BY-SA 3.0
2017-07-24T15:38:46.417Z
2017-07-25T00:42:56.837Z
2017-07-25T00:42:56.837Z
Edwin Torres
<p>If you already use an IDE, this could be the right way for you:</p>
<h2>Git support in your IDE</h2>
<p>Many IDEs come bundled with Git support:</p>
<ul>
<li><a href="https://code.visualstudio.com/" rel="nofollow noreferrer">Visual Studio Code</a> has maybe the best Git integration I've ever seen.</li>
<li><a href="https://eclipse.org/" rel="nofollow noreferrer">Eclipse</a> uses <a href="https://www.eclipse.org/egit/" rel="nofollow noreferrer">EGit</a> for Git integration.</li>
<li>The <a href="https://www.jetbrains.com/" rel="nofollow noreferrer">JetBrains IDEs</a> (IntelliJ, PyCharm etc.) also provide Git support.</li>
</ul>
<p>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.</p>
<p>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.</p>
<hr />
<p>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.</p>

CC BY-SA 3.0
2017-07-24T16:17:27.253Z
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
CC BY-SA 3.0
2017-07-24T16:47:56.410Z
@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
CC BY-SA 3.0
2017-07-24T18:41:14.547Z
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
CC BY-SA 3.0
2017-07-24T22:28:38.067Z
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
CC BY-SA 3.0
2017-07-25T07:17:10.887Z
I don't like the Visual Studio plugin. Things like "sync" give me the impression they're trying to make git fit the old tfs-sc model. I write C# for a living, but I use git extensions. Their "it's okay, you can act like it's still tfs" model is not good for anyone imho, but especially for someone trying to learn git.
Nathan
CC BY-SA 3.0
2017-07-25T08:19:43.517Z
@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
CC BY-SA 3.0
2017-07-25T10:58:06.393Z
@NathanCooper It's a matter of taste. I find it quite clean, simple and easy to use, while keeping the CLI and GitExtensions for the things you really shouldn't be doing as part of normal work. I certainly prefer right clicking a commit in history to do my hard resets, rather than blindly deleting the last ten commits (or was it nine? Dammit...). The only thing that is a strong part of the "TFS-but-on-Git" IMO is that it's optimised for a single central Git repository - which scarcely seems like a bad choice for a typical corporate customer. Not every software project is a Linux kernel :P
Luaan
CC BY-SA 3.0
2017-07-25T13:43:10.070Z
@CAD97 good to know! I haven't used IntelliJ IDEs too much lately, just in my free time playing around, since I work at a Microsoft-shop. So I haven't needed to delve into the IDE's git capabilities too much. I'll keep that in mind, though. Cheers!
Daevin
CC BY-SA 3.0
2017-07-25T13:49:43.667Z
@NathanCooper I actually do like the "sync" capability, it's just a single command for fetch-pull-push. Especially since I've had to 'teach' git to some coworkers and so many can't be bothered to to multiple commands, the "Commit and Sync" button is a life(repo)-saver lol.
Daevin
CC BY-SA 4.0
2017-07-24T11:14:40.853Z
2022-08-09T19:22:08.697Z
2022-08-09T19:22:08.697Z
TuringTux
<h1>1) Use the built-in Git GUI</h1>

<p><strong>Git actually includes a <a href="https://git-scm.com/docs/git-gui" rel="noreferrer">built-in user interface</a> known as git-gui which is great for novices learning Git for the first time.</strong> It's fairly simple to use, comes <a href="https://git-scm.com/downloads" rel="noreferrer">standard with Git</a>, and is available on Windows, Mac OS X, and Gnu/Linux.</p>

<p>Git-gui has a very simple interface that <strong>visually displays</strong> the process of staging files, creating commits, viewing project history, amending the last commit, creating branches, local merging, fetching/pushing to remote repositories. <strong>It also includes easy access to Git Bash in your command line of choice</strong> 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)</p>

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

<p><strong><a href="https://git-scm.com/downloads" rel="noreferrer">Download Git for Windows/Mac/Linux/Solaris</a></strong></p>

<p><a href="https://i.sstatic.net/AJtMd.png" rel="noreferrer"><img src="https://i.sstatic.net/AJtMd.png" alt="Git Gui screenshot"></a></p>

<h1>2) Contribute to an existing project</h1>

<p>I first learned Git because I wanted to contribute to the <a href="https://github.com/dolphin-emu" rel="noreferrer">Dolphin Emulator</a>. 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.</p>

<p>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.</p>

<p>In short, <a href="https://github.com/explore" rel="noreferrer">find a project you are passionate about</a> 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.</p>

<p><strong>No contribution is too small, <a href="https://github.com/notepad-plus-plus/notepad-plus-plus/pull/3154" rel="noreferrer">even if it's just changing the wording for a single menu option</a>.</strong></p>

CC BY-SA 3.0
2017-07-25T13:30:57.930Z
Seconding Git GUI and in particular gitk (under repository->visualize all branch history) for visualizing the current state of affairs.
Sumyrda - remember Monica
CC BY-SA 3.0
2017-07-25T14:34:37.090Z
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.
CC BY-SA 3.0
2017-07-24T17:28:55.227Z
2017-12-06T23:23:49.313Z
2017-12-06T23:23:49.313Z
Stevoisiak
<p>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 <a href="http://hginit.com/" rel="noreferrer">http://hginit.com/</a>). 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 <a href="https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=1&amp;cad=rja&amp;uact=8&amp;ved=0ahUKEwi_noz9uKTVAhUlxoMKHWfSCWcQyCkIKDAA&amp;url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D1ffBJ4sVUb4&amp;usg=AFQjCNGtT3vLapyMNS-6a3Fl7fEVTaRlJw" rel="noreferrer">Git for Ages 4 and Up</a> 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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-07-26T12:21:50.053Z
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
CC BY-SA 3.0
2017-07-26T14:46:42.567Z
@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
CC BY-SA 3.0
2017-07-25T12:50:00.770Z
2017-07-25T12:50:00.770Z
moneyt
<p>I have students follow through the <a href="https://www.learnenough.com/git-tutorial" rel="nofollow noreferrer">Learn Enough Git to Be Dangerous</a> tutorial, which goes through the basics of setting up a repo, committing, pushing to GitHub, and some simple collaboration. </p>

<p>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.</p>

CC BY-SA 3.0
2017-08-25T01:04:07.920Z
2017-12-13T01:20:31.050Z
2017-12-13T01:20:31.050Z
hummus
<h2>Help students make improvements to a toy website with git &amp; Github</h2>

<p>I have taught git and Github basics with <a href="http://wiki.openhatch.org/Open_Source_Comes_to_Campus/Practicing_Git" rel="noreferrer">this activity from OpenHatch</a>. 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.</p>

<p>In the activity, small groups work to improve a small website housed in <a href="https://github.com/openhatch/github-website-editing-demo" rel="noreferrer">a Github repo</a>. The site is also hosted on Github, so they can see changes immediately. <a href="https://github.com/openhatch/github-website-editing-demo/issues" rel="noreferrer">Issues are available in the repo</a> 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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-07-24T22:06:57.020Z
2017-07-24T22:54:25.427Z
2017-07-24T22:54:25.427Z
nova
<p>I remember initially struggling with Git.</p>

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

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

<p>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.</p>

<p><a href="https://cseducators.stackexchange.com/a/2921">FallenNode's answer</a> gives you the gem that is <a href="http://learngitbranching.js.org" rel="nofollow noreferrer">LearnGitBranching</a>, which serves this very purpose. I can't recommend it enough.</p>

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

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

<p>Useful resources:</p>

<ul>
<li><a href="https://try.github.io" rel="nofollow noreferrer">https://try.github.io</a></li>
<li><a href="https://git-scm.com/book" rel="nofollow noreferrer">https://git-scm.com/book</a></li>
<li><a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">http://nvie.com/posts/a-successful-git-branching-model/</a></li>
</ul>

<hr>

<p>[*] <em>I'll give just one such example:</em></p>

<p><code>git cherry-pick nameofsomebranch</code></p>

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

CC BY-SA 3.0
2017-07-24T21:24:23.783Z
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
CC BY-SA 3.0
2017-07-24T21:29:19.537Z
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
CC BY-SA 3.0
2017-07-25T14:17:47.207Z
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
CC BY-SA 3.0
2017-07-25T14:38:14.803Z
...which is again why you should start with Git GUI, which gives you a nice graphical picture of the DAG.
T.E.D.
CC BY-SA 3.0
2017-07-24T16:42:44.583Z
2017-12-14T06:25:21.660Z
2017-12-14T06:25:21.660Z
Tobia Tesan
<p>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 <a href="https://www.codecademy.com/learn/learn-git" rel="nofollow noreferrer">the Codecademy git tutorial</a></p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-07-24T15:38:51.833Z
2017-12-13T01:25:58.253Z
2017-12-13T01:25:58.253Z
SgtOVERKILL
<h1>How do I teach git to a teenager</h1>

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

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

<h2>What can I do to make this journey easier for me?</h2>

<p>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.</p>

<h2>What good user interfaces should I adopt?</h2>

<blockquote>
  <h3>My preference for interfaces are</h3>
  
  <ul>
  <li>Unix (GNU/Linux) command line</li>
  <li>Unix (GNU/Linux) GUI</li>
  <li>Microsoft's Windows GUI</li>
  <li>Microsoft's command line</li>
  </ul>
  
  <p>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.</p>
</blockquote>

<p>Without hesitation, you should use the official release client from <a href="https://git-scm.com/downloads" rel="nofollow noreferrer">git-scm.com</a> to meet your requirements. The command line tools and git-gui are included. On Fedora (27) Gnu/Linux, you type <code>sudo dnf install git git-gui</code>, and you are done and ready.</p>

<p>Git-gui is a commit tool (<code>git citool</code> to launch the commit interface tool), I mostly use <code>gitk</code> 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.</p>

<p>If you want a GUI that is a little less encumbering, I recommend <a href="https://wiki.gnome.org/Apps/Gitg/" rel="nofollow noreferrer">Gitg</a> 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 <code>sudo dnf install gitg</code> and type <code>gitg</code> 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.</p>

<h2>My goal</h2>

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

<p>The best resources are tested. Grab yourself a copy of <a href="https://github.com/Willtech/GitRefDocs/raw/master/git.from.bottom.up.pdf" rel="nofollow noreferrer">Git from the bottom up</a> and <a href="https://git-scm.com/book/en/v2" rel="nofollow noreferrer">Pro Git</a> (both under CC licence).</p>

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

<p>In order to achieve your goals you are going to have to consider two things:</p>

<ol>
<li>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.</li>
<li>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.</li>
</ol>

<p>Remember, you can always type <code>git commit --help</code> etc. for almost anything.</p>

<p>Good luck!</p>

CC BY-SA 3.0
2018-03-12T12:20:55.430Z
Welcome to [cseducators.se]! This is a wonderfully detailed answer! I hope we'll see more contributions from you in the future.
ItamarG3
CC BY-SA 3.0
2018-03-12T07:17:26.313Z
2018-03-12T12:42:22.353Z
2018-03-12T12:42:22.353Z
Willtech
<p>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:</p>

<ul>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>You work with keystrokes, just as you would at the command line. This means you don't have a mouse slowing you down.</p></li>
<li><p>You will quickly learn to do common operations fast.</p></li>
</ul>

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

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

CC BY-SA 3.0
2017-08-08T18:28:05.667Z
2017-09-14T07:45:10.483Z
2017-09-14T07:45:10.483Z
Norman Ramsey
<h2>What worked for me...</h2>

<p>was working with Git. </p>

<p>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.</p>

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

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

<p>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. </p>

<p>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).</p>

<p>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.</p>

<p>That was 2016-2017.</p>

<p>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. </p>

<h3>Recap</h3>

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

<p>A few months later (especially after reading <a href="https://git-scm.com/book/en/v2" rel="nofollow noreferrer">this excellent book</a>—several times), I was a bit of a wizard. </p>

<p>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.</p>

<p>Passion is such a great teacher. </p>

CC BY-SA 4.0
2020-01-18T14:14:44.600Z
The opportunity to write this answer means I need to go rewrite the intro of my workshop. Thank you.
D. Ben Knoble
CC BY-SA 4.0
2020-01-18T15:15:05.103Z
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
CC BY-SA 4.0
2020-01-18T15:18:26.300Z
@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
CC BY-SA 4.0
2020-01-18T15:31:00.163Z
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
CC BY-SA 4.0
2020-01-21T02:49:58.790Z
@ctrl-alt-delor I've just read about [Tower](https://www.git-tower.com/mac) (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
CC BY-SA 4.0
2020-01-22T07:46:58.933Z
@DBenKnoble it looks to be proprietary. I am not going back in to prison. So much too loose, one thing to gain. It is a shame that git (GPL licences software, and written be the creator of one of the largest GPL projects), needs proprietary software to be usable. I will continue looking.
ctrl-alt-delor
CC BY-SA 4.0
2020-01-18T14:13:56.950Z
2020-01-20T12:30:45.537Z
2020-01-20T12:30:45.537Z
D. Ben Knoble
<p>It was @Torek over at stackoverflow  who made a comment  which I believe is the nub of the problem. It went something like</p>
<blockquote>
<p>The git implementers tend to emphasize  implementation over policy</p>
</blockquote>
<p>It is the corollary to this that is hitting you and your students viz</p>
<blockquote>
<p>git is badly documented not in the sense that documentation is absent but in the sense that</p>
<ul>
<li>chockful of too many details</li>
<li>badly ordered</li>
<li>abstractions either absent</li>
<li>Or leaky</li>
<li>Poor/absent precis/for-dummies docs — you never know when you've stumbled onto an internal detail or poweruser tool</li>
<li>All plastered over with endless fanboyism</li>
</ul>
</blockquote>
<p>Case in point</p>
<h1>Lineendings</h1>
<h2>History Capsule</h2>
<p>In the beginning  Linus Torvalds made cavalier  comments about the fact that git only dealt with <em>data</em>, ie bytes, and he could not  care less about <code>lf</code> vs <code>crlf</code> 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 <code>lf</code>.</p>
<p>As the net widened to Microsoft's Windows users it became clear that this was an untenable assumption; &quot;Cured&quot; by the hack called <code>autocrlf</code>.</p>
<p>When git comprehensively knocked out all the other versioning competition the clunkyness of the autocrlf-hack and its epidemic consequences emerged.
Later &quot;Cured&quot; by <code>gitattributes</code> replacing <code>autocrlf</code>.</p>
<p>No doubt <code>gitattributes</code> is a vast improvement over <code>autocrlf</code>, but (in by humble opinion) not nearly enough.</p>
<p>Following I'll try and elaborate what's wrong.</p>
<p><a href="https://stackoverflow.com/a/59644154/3700414">This answer</a> of mine is at a more practical level: with the current git feature-set how to work round the issues.</p>
<p>For here I'd like to take a more hi-level view</p>
<h2>Philosophical gaffes and Pedagogical consequences</h2>
<p>A binary file is a sequence of bytes</p>
<p>A text file is different.
It's a sequence of <em>lines</em> each of which is a sequence of <em>char</em>s</p>
<p>That one can be serialized as the other is an irrelevancy. The relevant point is that as data-structures they are different.</p>
<p>And so if I ask you</p>
<blockquote>
<p>Do you work on an lf or a crlf OS?</p>
</blockquote>
<p>The most reasonable (and polite) answer you can respond with is</p>
<blockquote>
<p>That's none of your business</p>
</blockquote>
<p>In the same way that</p>
<blockquote>
<p>What is the color of your shirt (or skin)?</p>
</blockquote>
<p>is answered.</p>
<p>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 &lt;br/&gt;s and actually disappear!</p>
<p>And in all these cases questions about this are best handled with</p>
<ul>
<li>not your business</li>
<li>not relevant</li>
<li><a href="https://en.wikipedia.org/wiki/Not_even_wrong" rel="nofollow noreferrer">not even wrong</a></li>
<li>etc</li>
</ul>
<p>Instead...</p>
<h1>Git does it wrong all over</h1>
<ul>
<li>Messages such as <code>lf will be replaced by crlf</code></li>
<li>Documentation that is clunky and unabstract  eg <code>git stores text as lf</code>. Why is this anyone's business (other than git plumbing implementer's?) Following from</li>
<li>Abstractions that leak all over. Eg discussions in terms of lf/crlf files rather than nix-text Vs windows-text. All resulting in...</li>
<li>Erroring out too late at the wrong time and place. Eg safecrlf true only by intention not by default.</li>
</ul>
<h1>Suggestions</h1>
<p>If you want a lightweight graduated introduction to version control you can consider</p>
<ul>
<li><p><a href="https://en.wikipedia.org/wiki/Revision_Control_System" rel="nofollow noreferrer">RCS</a> (*nix only)</p>
</li>
<li><p><a href="https://en.wikipedia.org/wiki/Fossil_(software)" rel="nofollow noreferrer">Fossil</a></p>
</li>
<li><p>etc</p>
</li>
</ul>
<p>Not suggestions I make too willingly : git has comprehensively won the version-war and avoiding it is just postponing.</p>
<p>So if we realize that we must willy-nilly bite the bullet, the other answers here do a better job than I can.</p>
<p>All I'll say is not too constructive: the <em>docs</em> are the problem more than the <em>design</em>. Concentrate there.</p>
<hr />
<h2>Added later</h2>
<p>I just <a href="https://stackoverflow.com/questions/73009368/getting-the-warning-message-in-the-working-copy-of-file-path-crlf-will-be-re#comment128952688_73009368">discovered</a> the hilarious fact that the old message <code>LF will be replaced by CRLF</code> is now flipped to <code>CRLF will be replaced by LF</code> <strong>for the same problem!!</strong>.</p>
<p>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.</p>

CC BY-SA 4.0
2020-01-21T13:24:32.027Z
Upvoted because I learned something, but all of the sentence fragments make this answer quite difficult to follow.
Ben I.
CC BY-SA 4.0
2020-01-22T08:00:39.117Z
I fixed some grammar, but it still needs proof reading and fixing.
ctrl-alt-delor
CC BY-SA 4.0
2020-01-22T08:01:57.707Z
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
CC BY-SA 4.0
2020-01-22T10:10:02.000Z
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
CC BY-SA 4.0
2020-01-22T13:17:34.963Z
@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
Rushi
CC BY-SA 4.0
2020-01-22T13:18:49.350Z
que...........?
ctrl-alt-delor
CC BY-SA 4.0
2020-01-21T07:29:24.677Z
2022-08-10T04:53:06.950Z
2022-08-10T04:53:06.950Z
Rushi
<p>The first resource I give to students is this one: <a href="https://try.github.io/levels/1/challenges/1" rel="nofollow noreferrer">https://try.github.io/levels/1/challenges/1</a>.</p>

<p>I've heard great things about <a href="http://patchwork.github.io/" rel="nofollow noreferrer">Github Patchwork</a> - 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.</p>

CC BY-SA 3.0
2017-08-20T20:09:59.123Z
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
CC BY-SA 3.0
2017-07-24T14:42:55.820Z
2017-07-24T14:42:55.820Z
CS Cheerleader
<p>There are a few cornerstones to master to establish a good foundation for understanding and using Git.</p>

<p><strong>Purpose</strong></p>

<p>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.</p>

<p><strong>Inner Workings</strong></p>

<p>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.</p>

<p><strong>Visualization</strong></p>

<p>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.</p>

<pre><code>[alias]
    lol = log --graph --decorate --pretty=oneline --abbrev-commit
    lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
</code></pre>

<p>By fostering these fundamentals, the only thing between novice and expert is experience.</p>

CC BY-SA 3.0
2017-07-24T21:08:46.207Z
Welcome to [cseducators.se]! This is a very nice answer. I hope we'll be getting more answers and questions from you :)
ItamarG3
CC BY-SA 3.0
2017-07-25T00:47:59.207Z
Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/62755/discussion-on-answer-by-harrichael-how-to-make-git-easy-to-learn).
thesecretmaster
CC BY-SA 3.0
2017-07-24T21:00:28.617Z
2017-07-24T21:00:28.617Z
Harrichael
<p>I learned Git several years ago by reading <a href="https://git-scm.com/book/en/v2" rel="nofollow noreferrer">Pro Git</a>. 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.</p>

CC BY-SA 3.0
2017-07-26T04:39:12.520Z
2017-07-26T04:39:12.520Z
Code-Apprentice
<p>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.</p>
<p>(This question is about learning to use Git. Not about comparing it to other revision control systems.)</p>
<p>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 (<code>hg</code>) — a similar, but easier to use revision control tool.</p>
<p>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.</p>
<p>What can I do to make this journey easier for me?</p>
<p>What good user interfaces should I adopt?</p>
<p>I am not interested in proprietary tools; All tools should be <strong>Free Software / Open Source</strong>. They need to be available for <strong>GNU/Linux</strong> and <strong>Microsoft Windows</strong> (I have to use the latter at work).</p>
<hr />
<h2>Who are the learners?</h2>
<ul>
<li>Myself (<strong>a software engineer &gt; 20 years experience of revision control systems</strong>).</li>
<li>My pupils (age 11 to 18), if I find it easy enough to learn my self.</li>
</ul>
<h2>My preference for user interfaces are</h2>
<ul>
<li>Unix (GNU/Linux) command line.</li>
<li>Unix (GNU/Linux) GUI.</li>
<li>Microsoft's Windows GUI.</li>
<li>Microsoft's command line.</li>
</ul>
<p>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.</p>
<h2>My goals</h2>
<ul>
<li>To use the tool to store the history of my, and pupils, projects.</li>
<li>To be able to look at past history.</li>
<li>To be able to revert to past state.</li>
<li>To merge and resolve conflicts.</li>
<li>To not be un-necassarily serprised.</li>
<li>To never think, that life would be easier without it.</li>
<li>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).</li>
</ul>
<p><a href="https://i.sstatic.net/57pAQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/57pAQ.png" alt="XKCD comic. Man gesturing to a laptop: &quot;This is Git. It tracks collaborative work on projects through a beautiful distributed graph theory tree model.&quot; Woman: &quot;Cool. How do we use it?&quot; Man: &quot;No idea. Just memorize these shell commands and type them to sync up. If you get errors, save your work elsewhere, delete the project, and download a fresh copy.&quot;" /></a></p>
<p>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.</p>

CC BY-SA 3.0
2017-07-24T14:44:09.887Z
What specifically do you want to do with Git? A large majority of users probably just [know the basics and reset their repo if things go wrong](https://imgs.xkcd.com/comics/git.png), unless you specifically need some of the advanced features (e.g. `git bisect`), so having a specific goal might be helpful here for others to guide you more accurately.
Aurora0001
CC BY-SA 3.0
2017-07-24T16:50:08.180Z
I'm not sure this is a question about CS. Probably should be moved to SuperUser?
Tobia Tesan
CC BY-SA 3.0
2017-07-24T17:29:00.767Z
@TobiaTesan Learning material recommendations are [not on-topic for Super User](https://superuser.com/help/on-topic), unfortunately, so migration would not be appropriate here.
Aurora0001
CC BY-SA 3.0
2017-07-24T17:54:13.257Z
@TobiaTesan I want my CS students and I to use git for their CS programming project.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-27T12:24:26.350Z
@gbr You could've said that a little more nicely, I have feelings too :) But, if you wanted to reach me it would have been much easier to simply raise a mod atten flag. Keep in mind, that ["Comments are temporary "Post-It" notes left on a question or answer. You should not expect them to be around forever"](https://meta.stackexchange.com/a/19757/303538) (from the faq). I've [moved the conversation to chat, if you'd like to continue it](http://chat.stackexchange.com/rooms/62918/discussion-on-question-by-richard-how-to-make-git-easy-to-learn).
thesecretmaster
CC BY-SA 3.0
2017-09-14T07:49:03.080Z
see video [Git For Ages 4 And Up](https://www.youtube.com/watch?v=1ffBJ4sVUb4) for a good explanation of how git works (the model). [extracted from a deleted answer: answer to short.] It does not explain how to use git. But knowing the internal model may be a prerequisite.
ctrl-alt-delor
CC BY-SA 3.0
2018-01-20T10:40:15.827Z
The many links to tutorials, have confirmed my belief that `git` is the assembler-language of revision control: A thin layer over the machine-code, that is explained in the tutorials. One day a spiritual descendent of Grace Hopper (and also has some time) will come along and write a decent interface for it. In the meantime there is mercurial (`hg`).
ctrl-alt-delor
CC BY-SA 3.0
2018-02-02T14:53:50.057Z
`To never think, that live would be easier without it` Historically, people have had the same idea about having a HDD, or having a network share, or having a _backupped_ network share. Expectations change as the technology evolves. It's possible that in the near future, Git will become the outdated approach compared to the newly developed tool which makes life so much easier, and you'll be saying `To never think, that live would be easier without [new tool]`. _This, too, will pass._
Flater
CC BY-SA 3.0
2018-02-02T15:36:18.827Z
@Flater that is normal. If you have only used one revision-control-system/operating-system. You can not imagine using anything else or not using it. Even if it is the hardest of its type to use.
ctrl-alt-delor
CC BY-SA 3.0
2018-03-08T12:41:43.967Z
Good luck my friend. I personally would not attempt to teach Git at that level. It's more of a "workplace training" type of thing. Of all the people I've introduced to Git, I don't think any of them "git" it, (pun hahahaha). Even myself, I'd rather just kill a repo when it goes sideways than fix it as intended. I mostly use Git as a punchcard...
Gorchestopher H
CC BY-SA 3.0
2018-03-10T17:43:11.863Z
[My own presentation on Git](https://youtu.be/j6Se3jH60dA) has gotten rave reviews from beginners and veteran users alike.
Wildcard
CC BY-SA 3.0
2018-03-10T20:44:26.760Z
@wildcard nice presentation. I am still looking for how to learn HOW. However I learnt some new stuff about the internals, my view of it is now simpler/cleaner. If people are needing 5 days training, then it must be too complex. I will stick with mercurial.
ctrl-alt-delor
CC BY-SA 3.0
2018-03-10T22:02:06.620Z
@ctrl-alt-delor, actually, no one has needed 5 day training so far.  I think you would do your students a great service to get them a clean insight into its structure—they'll find it very handy for their future careers.
Wildcard
CC BY-SA 3.0
2018-03-11T19:16:39.740Z
@Wildcard I am currently using Mercurial (very similar to git, but easy to use), as it is easier to use and teach. When I teach theory, such as directed graphs, I use git as a case study. Your video helped me to better understand then internals. The problem I am having is not on understanding the internals, but on the UI. Both graphical and command line seem unintuitive. However both the command line and tortoise are very intuitive for both mercurial and subversion. Do you have any tips on getting my head around the UI?
ctrl-alt-delor
CC BY-SA 3.0
2018-03-11T19:20:15.233Z
@ctrl-alt-delor I never use the UI locally.  But you might try GitLab—unlike GitHub, you can install it on your own server for free.  It has a very clean UI, very conductive to collaboration.  I use Git (a) via command line and (b) via GitLab.
Wildcard
CC BY-SA 3.0
2018-03-11T19:39:17.313Z
@Wildcard How do I checking a working copy directory, if I only use the UI on the server? Is this possible. I am struggling to see what the work flow would be.
ctrl-alt-delor
CC BY-SA 3.0
2018-03-11T19:41:13.870Z
@ctrl-alt-delor you can make edits and commit them directly through the UI—but I prefer using the command line, and my editor of choice, for all but the most trivial changes.
Wildcard
CC BY-SA 3.0
2018-03-11T19:44:35.420Z
@Wildcard Sorry my confusion, I was using UI to mean User Interface, including Graphical User Interface, command line, and what ever else you may think of. I prefer the command line for most tasks, but I don't get git. It always seems to surprise me.
ctrl-alt-delor
CC BY-SA 3.0
2018-03-11T22:15:01.470Z
@ctrl-alt-delor, tell you what, this is growing far beyond comments on this question.  Can you shoot me an email?  (Address is in the presentation you watched, right near the end.)
Wildcard
CC BY-SA 3.0
2018-03-15T10:06:09.123Z
Beginners can use it mostly like svn. ``git commit -a``, ``git push``, ``git pull``, ``git merge``. And the complicated (and powerful) features are not even used by most professionals.
allo
CC BY-SA 3.0
2018-03-15T10:50:05.387Z
@allo, but I like `push` and `pull`. And I think that is my point “the powerful features are not even used by most professionals,” [because they are so complicated].
ctrl-alt-delor
CC BY-SA 3.0
2017-11-21T01:44:56.960Z
My opinion plus 50 cents will get you a bad cup of coffee. The best way to use git, IMHO,  is to not use it (polite version). I have only twice executed a successful pull from git, and can't figure out for the life of me how I did it.  I'll take obfuscated C over git any day.
pojo-guy
<resource-request><self-learning><revision-control><git>
How do I teach git to a teenager
# How do I teach git to a teenager

(Asked by: username_0 on 2017-07-24)

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

[![XKCD comic. Man gesturing to a laptop: ](https://i.sstatic.net/57pAQ.png)](https://i.sstatic.net/57pAQ.png)

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.

**Tags:** resource-request, self-learning, revision-control, git

> **Comments:**
> **username_1**: What specifically do you want to do with Git? A large majority of users probably just [know the basics and reset their repo if things go wrong](https://imgs.xkcd.com/comics/git.png), unless you specifically need some of the advanced features (e.g. `git bisect`), so having a specific goal might be helpful here for others to guide you more accurately.  
> **username_2**: I'm not sure this is a question about CS. Probably should be moved to SuperUser?  
> **username_1**: @TobiaTesan Learning material recommendations are [not on-topic for Super User](https://superuser.com/help/on-topic), unfortunately, so migration would not be appropriate here.  
> **username_0**: @TobiaTesan I want my CS students and I to use git for their CS programming project.  
> **username_3**: @gbr You could've said that a little more nicely, I have feelings too :) But, if you wanted to reach me it would have been much easier to simply raise a mod atten flag. Keep in mind, that ["Comments are temporary "Post-It" notes left on a question or answer. You should not expect them to be around forever"](https://meta.stackexchange.com/a/19757/303538) (from the faq). I've [moved the conversation to chat, if you'd like to continue it](http://chat.stackexchange.com/rooms/62918/discussion-on-question-by-richard-how-to-make-git-easy-to-learn).  
> **username_0**: see video [Git For Ages 4 And Up](https://www.youtube.com/watch?v=1ffBJ4sVUb4) for a good explanation of how git works (the model). [extracted from a deleted answer: answer to short.] It does not explain how to use git. But knowing the internal model may be a prerequisite.  
> **username_8**: My opinion plus 50 cents will get you a bad cup of coffee. The best way to use git, IMHO,  is to not use it (polite version). I have only twice executed a successful pull from git, and can't figure out for the life of me how I did it.  I'll take obfuscated C over git any day.  
> **username_0**: The many links to tutorials, have confirmed my belief that `git` is the assembler-language of revision control: A thin layer over the machine-code, that is explained in the tutorials. One day a spiritual descendent of Grace Hopper (and also has some time) will come along and write a decent interface for it. In the meantime there is mercurial (`hg`).  
> **username_4**: `To never think, that live would be easier without it` Historically, people have had the same idea about having a HDD, or having a network share, or having a _backupped_ network share. Expectations change as the technology evolves. It's possible that in the near future, Git will become the outdated approach compared to the newly developed tool which makes life so much easier, and you'll be saying `To never think, that live would be easier without [new tool]`. _This, too, will pass._  
> **username_0**: @username_4 that is normal. If you have only used one revision-control-system/operating-system. You can not imagine using anything else or not using it. Even if it is the hardest of its type to use.  
> **username_5**: Good luck my friend. I personally would not attempt to teach Git at that level. It's more of a "workplace training" type of thing. Of all the people I've introduced to Git, I don't think any of them "git" it, (pun hahahaha). Even myself, I'd rather just kill a repo when it goes sideways than fix it as intended. I mostly use Git as a punchcard...  
> **username_6**: [My own presentation on Git](https://youtu.be/j6Se3jH60dA) has gotten rave reviews from beginners and veteran users alike.  
> **username_0**: @wildcard nice presentation. I am still looking for how to learn HOW. However I learnt some new stuff about the internals, my view of it is now simpler/cleaner. If people are needing 5 days training, then it must be too complex. I will stick with mercurial.  
> **username_6**: @username_0, actually, no one has needed 5 day training so far.  I think you would do your students a great service to get them a clean insight into its structure—they'll find it very handy for their future careers.  
> **username_0**: @username_6 I am currently using Mercurial (very similar to git, but easy to use), as it is easier to use and teach. When I teach theory, such as directed graphs, I use git as a case study. Your video helped me to better understand then internals. The problem I am having is not on understanding the internals, but on the UI. Both graphical and command line seem unintuitive. However both the command line and tortoise are very intuitive for both mercurial and subversion. Do you have any tips on getting my head around the UI?  
> **username_6**: @username_0 I never use the UI locally.  But you might try GitLab—unlike GitHub, you can install it on your own server for free.  It has a very clean UI, very conductive to collaboration.  I use Git (a) via command line and (b) via GitLab.  
> **username_0**: @username_6 How do I checking a working copy directory, if I only use the UI on the server? Is this possible. I am struggling to see what the work flow would be.  
> **username_6**: @username_0 you can make edits and commit them directly through the UI—but I prefer using the command line, and my editor of choice, for all but the most trivial changes.  
> **username_0**: @username_6 Sorry my confusion, I was using UI to mean User Interface, including Graphical User Interface, command line, and what ever else you may think of. I prefer the command line for most tasks, but I don't get git. It always seems to surprise me.  
> **username_6**: @username_0, tell you what, this is growing far beyond comments on this question.  Can you shoot me an email?  (Address is in the presentation you watched, right near the end.)  
> **username_7**: Beginners can use it mostly like svn. ``git commit -a``, ``git push``, ``git pull``, ``git merge``. And the complicated (and powerful) features are not even used by most professionals.  
> **username_0**: @username_7, but I like `push` and `pull`. And I think that is my point “the powerful features are not even used by most professionals,” [because they are so complicated].  

---

## 24 answers

### Answer by username_14 on 2017-07-24. Score: 52

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.

> **Comments:**
> **username_15**: 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).  
> **username_16**: I will check out this tutorial. Thanks! Also, welcome to [cseducators.se]! I hope we hear more from you in the future.  
> **username_17**: 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!*  
> **username_18**: +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] https://github.com/FredrikNoren/ungit  
> **username_0**: I understand the internal state. It is the UI that I struggle with.  
> **username_14**: If you're looking for a git UI there are many to choose from. I recommend [GitKraken](https://www.gitkraken.com/git-client).   A full list can be found at [https://git-scm.com/download/gui/windows](https://git-scm.com/download/gui/windows).  
> **username_10**: Relatedly, http://git-school.github.io/visualizing-git/ has a great visualizer playground. There are a few pre-set examples too.  

---

### Answer by username_23 on 2017-07-24. Score: 18

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](https://try.github.io/levels/1/challenges/1). Here's another, more comprehensive [one](https://www.atlassian.com/git/tutorials).

**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](https://github.com/), [Bitbucket](https://bitbucket.org/product), or [GitLab](https://gitlab.com/users/sign_in).

> **Comments:**
> **username_2**: 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.  

---

### Answer by username_11 on 2017-07-24. Score: 15

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](https://code.visualstudio.com/) has maybe the best Git integration I've ever seen.
* [Eclipse](https://eclipse.org/) uses [EGit](https://www.eclipse.org/egit/) for Git integration.
* The [JetBrains IDEs](https://www.jetbrains.com/) (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.

> **Comments:**
> **username_24**: 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.  
> **username_11**: @username_24 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 ;)  
> **username_24**: 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  
> **username_25**: 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).  
> **username_26**: I don't like the Visual Studio plugin. Things like "sync" give me the impression they're trying to make git fit the old tfs-sc model. I write C# for a living, but I use git extensions. Their "it's okay, you can act like it's still tfs" model is not good for anyone imho, but especially for someone trying to learn git.  
> **username_27**: @username_24 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.  
> **username_28**: @username_26Cooper It's a matter of taste. I find it quite clean, simple and easy to use, while keeping the CLI and GitExtensions for the things you really shouldn't be doing as part of normal work. I certainly prefer right clicking a commit in history to do my hard resets, rather than blindly deleting the last ten commits (or was it nine? Dammit...). The only thing that is a strong part of the "TFS-but-on-Git" IMO is that it's optimised for a single central Git repository - which scarcely seems like a bad choice for a typical corporate customer. Not every software project is a Linux kernel :P  
> **username_24**: @username_27 good to know! I haven't used IntelliJ IDEs too much lately, just in my free time playing around, since I work at a Microsoft-shop. So I haven't needed to delve into the IDE's git capabilities too much. I'll keep that in mind, though. Cheers!  
> **username_24**: @username_26Cooper I actually do like the "sync" capability, it's just a single command for fetch-pull-push. Especially since I've had to 'teach' git to some coworkers and so many can't be bothered to to multiple commands, the "Commit and Sync" button is a life(repo)-saver lol.  

---

### Answer by username_21 on 2017-07-24. Score: 14

# 1) Use the built-in Git GUI

**Git actually includes a [built-in user interface](https://git-scm.com/docs/git-gui) 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](https://git-scm.com/downloads), 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](https://git-scm.com/downloads)**

[![Git Gui screenshot](https://i.sstatic.net/AJtMd.png)](https://i.sstatic.net/AJtMd.png)

# 2) Contribute to an existing project

I first learned Git because I wanted to contribute to the [Dolphin Emulator](https://github.com/dolphin-emu). 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](https://github.com/explore) 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](https://github.com/notepad-plus-plus/notepad-plus-plus/pull/3154).**

> **Comments:**
> **username_29**: Seconding Git GUI and in particular gitk (under repository->visualize all branch history) for visualizing the current state of affairs.  
> **username_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.  

---

### Answer by username_11 on 2017-07-24. Score: 9

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](https://desktop.github.com/) ([source code available on GitHub](https://github.com/desktop/desktop)) 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](https://cseducators.stackexchange.com/users/1091/steven-vascellaro) points out in [his comment](https://cseducators.stackexchange.com/questions/2897/how-to-make-git-easy-to-learn#comment5973_2901), 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.

> **Comments:**
> **username_19**: gitkraken is a great cross platform graphical git GUI which I can recommend.  
> **username_11**: @DanielVestøl Nice idea! Why don't you write an answer suggesting GitKraken as client? It's not Open Source, so it doesn't fullfill OP's requirements in this point but neither does mine here - I'd love to hear from you ;)  
> **username_20**: 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.  
> **username_11**: @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.  
> **username_21**: 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.  
> **username_11**: @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.  
> **username_21**: @username_11 I'm not entirely sure where I'd fit it in.  
> **username_11**: @StevenVascellaro Probably below "[...] but appear strange to Git users who know e.g. the command line interface.". I think it would fit there nicely.  
> **username_21**: @username_11 Feel free to add it in how you see fit. If you want to, just hyperlink back to the comment  
> **username_22**: If the goal is to be able to use most basic features of Git e.g. branches, commits, etc., then using a GUI is great precisely because you don't have to learn git and it's intuitive. As many points out, although the question asks about *learning Git*, we all know that at the end of the day, most of us just mindlessly copy-paste the commands, often without knowing the deeper details. In such cases, it doesn't make sense to avoid using a GUI like GitHub Desktop. Personally, I would suggest teaching basic Git and then showing how to do the same with GitHub Desktop or another GUI for comparison.  

---

### Answer by username_31 on 2017-07-25. Score: 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](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi_noz9uKTVAhUlxoMKHWfSCWcQyCkIKDAA&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D1ffBJ4sVUb4&usg=AFQjCNGtT3vLapyMNS-6a3Fl7fEVTaRlJw) 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.

> **Comments:**
> **username_0**: 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).  
> **username_31**: @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  

---

### Answer by username_32 on 2017-08-25. Score: 5

I have students follow through the [Learn Enough Git to Be Dangerous](https://www.learnenough.com/git-tutorial) 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 by username_33 on 2017-07-24. Score: 5

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

I have taught git and Github basics with [this activity from OpenHatch](http://wiki.openhatch.org/Open_Source_Comes_to_Campus/Practicing_Git). 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](https://github.com/openhatch/github-website-editing-demo). The site is also hosted on Github, so they can see changes immediately. [Issues are available in the repo](https://github.com/openhatch/github-website-editing-demo/issues) 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 by username_2 on 2017-07-24. Score: 4

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.

[username_14's answer](https://cseducators.stackexchange.com/a/2921) gives you the gem that is [LearnGitBranching](http://learngitbranching.js.org), 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 ;)*

> **Comments:**
> **username_34**: 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?”  
> **username_0**: I would say that the interface to git isn't unintuitive sometimes, but I want it to not be unintuitive all of the time.  
> **username_35**: 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."  
> **username_30**: ...which is again why you should start with Git GUI, which gives you a nice graphical picture of the DAG.  

---

### Answer by username_36 on 2017-07-24. Score: 3

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](https://www.codecademy.com/learn/learn-git)

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 by username_37 on 2018-03-12. Score: 3

# 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](https://git-scm.com/downloads) 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](https://wiki.gnome.org/Apps/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](https://github.com/username_37/GitRefDocs/raw/master/git.from.bottom.up.pdf) and [Pro Git](https://git-scm.com/book/en/v2) (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!

> **Comments:**
> **username_38**: Welcome to [cseducators.se]! This is a wonderfully detailed answer! I hope we'll see more contributions from you in the future.  

---

### Answer by username_39 on 2017-08-08. Score: 2

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 by username_40 on 2020-01-18. Score: 2

## 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](https://git-scm.com/book/en/v2)—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.

> **Comments:**
> **username_40**: The opportunity to write this answer means I need to go rewrite the intro of my workshop. Thank you.  
> **username_0**: 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.  
> **username_40**: @username_0 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?  
> **username_0**: 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).  
> **username_40**: @username_0 I've just read about [Tower](https://www.git-tower.com/mac) (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.  
> **username_0**: @DBenKnoble it looks to be proprietary. I am not going back in to prison. So much too loose, one thing to gain. It is a shame that git (GPL licences software, and written be the creator of one of the largest GPL projects), needs proprietary software to be usable. I will continue looking.  

---

### Answer by username_41 on 2020-01-21. Score: 2

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](https://stackoverflow.com/a/59644154/3700414) 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 *char*s

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   
s and actually disappear!

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

* not your business
* not relevant
* [not even wrong](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Revision_Control_System) (\*nix only)
* [Fossil](https://en.wikipedia.org/wiki/Fossil_(software))
* 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](https://stackoverflow.com/questions/73009368/getting-the-warning-message-in-the-working-copy-of-file-path-crlf-will-be-re#comment128952688_73009368) 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.

> **Comments:**
> **username_16**: Upvoted because I learned something, but all of the sentence fragments make this answer quite difficult to follow.  
> **username_0**: I fixed some grammar, but it still needs proof reading and fixing.  
> **username_0**: While you perfectly identified the problem in the first section (+1), do you have a solution (other than use a different system)?  
> **username_0**: 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).  
> **username_41**: @username_0 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  
> **username_0**: que...........?  

---

### Answer by username_42 on 2017-07-24. Score: 2

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](http://patchwork.github.io/) - 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.

> **Comments:**
> **username_3**: 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.  

---

### Answer by username_43 on 2017-07-24. Score: 2

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.

> **Comments:**
> **username_38**: Welcome to [cseducators.se]! This is a very nice answer. I hope we'll be getting more answers and questions from you :)  
> **username_3**: Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/62755/discussion-on-answer-by-harrichael-how-to-make-git-easy-to-learn).  

---

### Answer by username_44 on 2017-07-26. Score: 2

I learned Git several years ago by reading [Pro Git](https://git-scm.com/book/en/v2). 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 by username_9 on 2017-07-24. Score: 1

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](https://bitbucket.org/snippets/robb-gosset/xKzKa/git-cheat-sheet).

Other than that Atlassian has a freely available git gui client for Mac and Windows called [sourcetree](https://www.sourcetreeapp.com/), I've found it pretty intuitive to learn and use. Following on from that there's another tool called [SmartGit](http://www.syntevo.com/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 by username_0 on 2017-10-14. Score: 1

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](http://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](http://teachingopensource.org/?s=git)

---

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 by username_10 on 2020-02-10. Score: 1

I'll start by echoing the fantastic resource in username_14'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 by username_11 on 2022-06-18. Score: 1

[Oh My Git!](https://ohmygit.org/) 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.

> **Comments:**
> **username_0**: I will try soon.  
> **username_11**: Nice, please feel free to share your experience here afterwards. I am excited to hear how it works out :)  

---

### Answer by username_12 on 2019-03-22. Score: 1

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](https://www.gitkraken.com/) 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](https://learngitbranching.js.org/). 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.

> **Comments:**
> **username_0**: Interesting, but no use for me (number 6) as it is a proprietary program (Not [Free](https://www.gnu.org/philosophy/free-sw.en.html)).  
> **username_12**: 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.  
> **username_0**: 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.  

---

### Answer by username_0 on 2017-11-02. Score: 0

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

> **Comments:**
> **username_0**: Can the person that down voted. please give feedback. Formative feedback (this is how you can do better, this is where you are wrong) is of value, Sumative feedback (grades) is not.  

---

### Answer by username_13 on 2017-08-20. Score: 0

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.

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.
Created a new project. Right away, they would give you straightforward instructions on what to do next from the command line. 
(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://username_13_sn@bitbucket.org/username_13_sn/demo_repo_1.git
git push -u origin master

I'm starting from scratch
git clone https://username_13_sn@bitbucket.org/username_13_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.

> **Comments:**
> **username_3**: What does this answer add to [this other answer about using the command line instead of a GUI and mentioning online git resources such as GitHub, GitLab, BitBucket, etc.](https://cseducators.stackexchange.com/a/2912/58)?  
> **username_13**: 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 :)  
> **username_13**: (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" :)  
> **username_3**: 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.  
> **username_13**: I am sorry man, but I really have nothing else to add. I thought this forum was about sharing experiences. I checked all the other answers. I believe things can be a little more succinct. If my answer is so bad (or spam, accidentally), I am sure it should and will get down voted into oblivion, and I will be schooled.   However, after your comments, I ran this page and all the answers including mine with my own students. So, I will stick with my answer and I do believe it adds some value to the discussion here.  
> **username_3**: Let's continue this conversation [in chat](http://chat.stackexchange.com/rooms/64170/discussion-on-answer-by-jay-how-to-make-git-easy-to-learn).  
> **username_0**: for a local project you need to do a `git init`.  

---

