26 ms·

How to teach Git

• bagrow 8y ago
  Having taught git several times within a data science course I find two concepts especially worth extra time: WHY there is a staging area, and what is the difference between “git” and “github”.
  • radarsat1 8y ago
    > WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?
    • altairiumblue 8y ago
      Isn't the staging area closer to an intermediary box? That's where it can get confusing.
      • detaro 8y ago
        Staging puts things in the box, commit closes the box, puts it on the pile with the other boxes, and gives you a new empty staging box.
        • Double_a_92 8y ago
          But why is it an extra step? It's basically just a "longterm" selection of what you want to commit.
          • detaro 8y ago
            Because you not always want to put everything in the box (and if you do, there's a shortcut to do it), and "git commit file1 folder/folder/ * .cpp folder/folder/ * .h ..." for a complex set would be annoying and require you to mentally keep track of it from the beginning. Many beginners will start by always doing "git commit -a" and that's fine, as long as they know there's an alternative once they need it.
            • url00 8y ago
              But why is the exceptional case the default? Surely, most of the time when you go to commit, it's all the files you've changed?
              • IggleSniggle 8y ago
                Not for me! I often find myself refactoring tangential features while producing a new one. Sometimes that will even intersect in a single file. But that refactoring doesn't come with any changes relevant to the feature I am working on in my branch. So I save them for their own isolated commit(s). While this doesn't happen on every commit, it probably happens for me about every other push. The alternative is bundling in a bunch of changes that have very little to do with the feature that my branch is ostensibly about. EDIT: Now that I think about it, I also have several repos where I have changes that I never intend to ever commit them, because they are development conveniences for me personally.
                • Accacin 8y ago
                  Same for me! Webpack config changes to cache settings, config changes to hit a different API for testing, using a different database for testing. Most of these live in my staging area and get stashed and popped when I switch branches/rebase.
              • elcomet 8y ago
                Almost never actually. I never commit all the changes in my repo (for big projects I often have some small changes in other places, I don't want to commit them)
    • Gys 8y ago
      For simple projects (like ppl experimenting with git) you will always want to save all changes. So why stage first ?
      • tux1968 8y ago
        Not everyone stays a beginner forever, and it's nice to have a tool that doesn't play to the lowest common denominator. It's really not that hard to just do a "git commit -a" if you want to avoid staging.
        • oblio 8y ago
          > Not everyone stays a beginner forever But the vast majority do, or at best become perpetual intermediates (https://blog.codinghorror.com/defending-perpetual-intermediacy/ https://blog.codinghorror.com/defending-perpetual-intermedia...). 99% of developers out there didn't need a power tool for source control (source control is already quite a power tool many devs can barely handle, even in SVN form...), yet here we are: Git is imposed everywhere, with its horrible UX.
          • tux1968 8y ago
            Git's UX isn't that bad if you're only cloning projects to build them locally and keep them updated. The UX only gets really crufty as you use more and more of the features.
    • scrollaway 8y ago
      Understanding the staging area first requires understanding the need for it: The need for atomic commits. The need to create commits that have specific changes in them and are not always a snapshot of the entire world below the git root exactly as is right now.
    • pjc50 8y ago
      People are very used to the web "save always" style: There is one document, and you're editing it. Most people will be familiar with the traditional desktop "save" model where you have to do something to make your changes permanent. People often then learn that there is a local file and some remote file: they can cope with a save -> upload workflow. Lots of traditional VCS turn this into a save -> commit workflow. Git adds two stages to this that people can't see the need for without understanding the internals: an extra step between save and commit, and an extra step after commit. (The discussion reminds me of all those people who think that if they just start by talking about monads then people will find Haskell easy and natural...)
      • rakoo 8y ago
        The don't need to understand the internals for this: just knowing that every save you do will be stored forever as-is makes you double-think about what you put inside
      • doubleunplussed 8y ago
        There are a whole bunch of layers now, though they're all useful. 1. Is my document saved? 2. Are the changes staged? 3. Are the changed committed? 4. Are the changes pushed to my fork on e.g. github? 5. Are the changes merged into the upstream repository on e.g. github?
    • JediWing 8y ago
      So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory, it would be a blind commit with no guarantee that things are working. Very rare is the situation that I can break out a list of files over here that are for feature A and some over there for feature B, and never the two shall interact. I think this is probably what most struggle with regarding the staging area, without being able to articulate it.
      • aurumpotest 8y ago
        I use it quite a lot, especially with `git add -p` to stage only parts of a file for an atomic commit.
        • url00 8y ago
          This has never made sense to me. I've seen others say that they commit only parts of a file. How does this scenario start? Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change?
          • acemarke 8y ago
            Partly, yes. Or, I'll be working on a task overall, and have to touch multiple files in the process. Then when I'm ready to commit, I review all the modified files on disk, and look for ways to break those down into smaller discrete logical changes. I prefer to avoid "big bang" commits as much as possible, because smaller individual commits are easier to inspect, easier to back out if necessary, and provide a better "story" when inspecting a file's history sometime down the road.
            • Someone 8y ago
              But then, you either never run/tested those smaller individual commits, or you have to do extra work (stash changes, test, restore stash) to do that. I do not see why a source control system should make it easier to make a commit that hasn’t ever existed on disk and thus cannot have been tested. I think the better model would be to stash your changes and have an diff editor between the on-disk working copy and the stashed version that allows you to commit a set of changes as several smaller, more coherent commits. That wouldn’t guarantee that each of those intermediate commits gets tested or even built, but it would guarantee that each smaller commit is in the on-disk copy at some time.
    • fdsak 8y ago
      probably related changes grouped together
    • tokyodude 8y ago
      My hurdle was 15-20yrs of no staging area from previous VCSes so the extra step took some time to understand why it was needed.
    • allenu 8y ago
      I think people find it difficult because for most beginners at git, they just want to put everything in the box. Having the option to put just some things in the box seems more complicated than needed. Obviously, as you get better with the tool, you realize the power of literally "staging" your changes into multiple commits, but as beginner, it's not even in your purview.
    • recursive 8y ago
      Yes, it requires more explanation than that. I've used git for years, and never really understood why staging is even a thing. Your example is an implementation of the box-putting algorithm, but it doesn't need to be mirrored in the put-box CLI. put-close-box file1 file2 This command could encompass all the putting and closing. Since you only close boxes when you are done putting things in it, I don't see a need or purpose to split it up. put-box file1 file2 close-box A closed box (commit) is always going to contain stuff that was put in it, so why separate commands?
      • ezrast 8y ago
        That's not convenient when you're putting things into the box piecemeal, especially with `git add -p`. A thing I do frequently is to run `git diff`, scan through it, and add files (or parts of files) one by one in a second terminal. Then I do a final review of the staging area (with `git diff --cached`) to make sure it only has the changes I want and commit. I'm the sole devops engineer at my company and my workflow is a bit more scattered than a typical developer's. Anyway, `git commit file1 file2` by itself is most of the way to being the put-close-box function you want; it just doesn't work for adding/deleting files from the repo. Seems like they could make a lot of people happy by closing that gap and letting `git add` be an intermediate-level feature.
        • recursive 8y ago
          To me, that ought to be a concern of the "porcelain", although no one uses that word anymore. CLI is particularly bad at certain types of interaction. So to compensate, a mitigation is moved into the underlying model of git. That mitigation is staging. The inconvenience of "piecemeal adding" could have easily been addressed in the UI layer using a more suitable presentation, rather than forcing all clients to follow the stage/commit dichotomy.
  • jordigh 8y ago
    The staging area is really an extraneous concept that isn't required. It's like a commit that isn't a commit. In Mercurial, I much prefer to just make it an actual commit in the draft phase (the default phase) and just keep rewriting that commit. Mercurial provides tools for both selectively adding and removing hunks from a commit (both `hg amend` and `hg uncommit` accept --interactive for hunk selection). If you're extra paranoid, you can make it a commit in the secret phase so it's not shared prematurely by accident. It's pretty much functionally equivalent and doesn't require an extra location in which your code can be. It's either in your working directory or in a commit. A bonus of this approach is that now you have a meta-history, hidden by default, of what you've "staged" and "unstaged". It's kind of like a reflog but with, in my opinion, a better UI. And of course, the index/cache/staging area in git doesn't use refs, so there's no reflog there.
  • nlawalker 8y ago
    I've helped move a couple teams (kicking and screaming) from TFS to git, and I start back even further than that - why is it so much more complicated than clicking a button to save and share my work, and what is the benefit of that complication?
  • tome 8y ago
    I'm very experienced with git, approaching expert level, and I don't use the staging area. I use git commit --verbose --patch and bypass the staging area entirely. I don't find it helpful.
• diegoperini 8y ago
  An honest criticism: If I had trouble with understanding the reason behind add->commit->push workflow, I would definitely have no idea what this article talks about when it says things like "merge, rebase, diamond shape". The flow chart looks almost exactly the same for "pull" and "pull --rebase". The only difference between the charts is the wording which has no meaning at all for a newbie.
  • leni536 8y ago
    > The flow chart looks almost exactly the same for "pull" and "pull --rebase". "pull" and "pull --rebase" can cause two kind of conflicts: 1. Merge or rebase conflict inside the repository. 2. The would-be merged or rebased HEAD conflicting with the dirty working directory. The article demonstrates the latter and it's the less important one as it's avoidable by pulling from a clean working directory or pulling a non-HEAD branch.
  • cyborgx7 8y ago
    This is an article, not for people who don't understand git, but for people who do understand git and want to explain it to others.
    • rachelmcarmena 8y ago
      Right, thanks!!
  • jamesb93 8y ago
    It sounds stupid but something that really simplified git to me as an absolute beginner about a year ago was the fact that it doesn't exist on GitHub. Knowing that git was just something that sat in the folder on your filesystem and monitored changes took away the notion that there is some kind of sync between your remote and local. Working just on my own laptop made me realise how intuitive all the commands and strategies for solving problems were. Then came pushing, pulling etc between branches and it all just fell into place.
    • benwaffle 8y ago
• meuk 8y ago
  Personally, I think using git from the commandline is too complicated for the purpose it serves in most companies. Using a git GUI works quite well for people inexperienced with git.
  • abhishekjha 8y ago
    Its opposite for me. I am very comfortable with the command line. It lets me do crazy things and if I mess up, quitely crawl back to the peaceful place. GUI integrations have some advantages but the knowledge is not transferrable. Different GUIs work differently but the commands stay the same. I think both can complement each other. I use Pycharm a lot and it is a lot easier to see diffs or file history there. I think the same can be done with cmd as well but I don’t think I ever bothered to learn advanced commands.
    • meuk 8y ago
      I like the commandline as well, but most of my coworkers are happy using a git GUI, and I can see why: 1. Most GUI's give you an overview of the changes before committing. 2. Most GUI's let you commit and push in one go, and also show unstaged changes so you don't forget to add/commit/push anything. 3. A good git GUI is explorative. Newbies just remember the icons to click at first, and they learn more by exploring menus and reading messages. 4. Commit histories are easier to view and filter. 5. Exotic steps are easier to do, since you don't have to remember commands you barely use. 6. Adding remotes is a piece of cake.
    • crispyambulance 8y ago
      > and if I mess up, quitely crawl back to the peaceful place. Ok, but getting to THAT level of comfort takes a long time and many failed attempts. While I understand why folks may want a GUI for git, I am continually amazed that there hasn't been an effort to "refactor" git commands so they're more consistent, easier to remember and easier to discover. It's a miracle that git has taken root so strongly, given it's shitty user experience. I've been using git for years, and STILL, I need my cheatsheets and google far more than I would ever admit in person. Anything that's outside of heavily practiced workflow-- and I'm in a world of confusion.
• mettamage 8y ago
  Some ideas on how to teach it non-verbally in class, regarding the add, commit, push workflow: In class I'd stand on my right side, so students see me on the left (people are more used to left to right motions because of reading). I'd demarcate the working directory, staging area and local repository non-verbally as 3 different spaces. My most right space (the student's left) was the working directory, my most right space (the student's right) was the local repository. Everytime I'd make a transition from one space to another through add or commit, I'd make a hand gesture when I'd say "add" or "commit". In order to add some humor (humor is rememerability) with push I'd point upwards to the ceiling as if I were looking to God. I'm not religious, but people got the reference and they all left out loud.
• darkpuma 8y ago
  I think the best thing you could do for novices is to avoid priming them with preconceptions of Git being difficult. Psyching people up before instructing them never seems to do people any good, yet it's very common.
  • etjossem 8y ago
    I agree with this. For many people who are learning Git for the first time, it's also their first experience with contributing code to a repository at all. The last thing you want to do is turn them off entirely, or gatekeep the profession to exclude people who aren't good at reading dense documentation. The best way to teach git is to get them comfortable with "Add, Commit, and Push" and then explain what's happening at each stage.
    • darkpuma 8y ago
      Despite using CVS and SVN for years, I was never truly comfortable with either. When I first learned git, it was like a breath of fresh air. Suddenly the VCS was behaving in predictable ways. Yet I'd put off learning git for two or three years because everybody was telling me "git is so much more confusing than subversion." I shouldn't have listened to them, and they shouldn't have said that! Maybe if somebody has already mastered subversion then git will confuse them a lot, but I'm not convinced even that is necessarily true. Regardless, it seems clear to me that novice users shouldn't be told that git is complicated.
• cyborgx7 8y ago
  Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".
  • Ajedi32 8y ago
    `git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.
    • deleted 8y ago
      [deleted]
    • creeble 8y ago
      +1 these, I wish they were default for git. Much better both for beginners and experienced users.
    • hoorayimhelping 8y ago
      git config --global alias.lg "log --color --graph --oneline --decorate" for easy copy-pasting. HN doesn't support backticks or triple backticks like a lot of markdown parsers. To get fixed-width fonts, you have to insert 4 paces at the beginning of the 'code' block.
      • Stratoscope 8y ago
        Two spaces (unlike Markdown). Of course four will work, it just adds more indentation.
        • u801e 8y ago
          In some mobile browsers, doing this will result in the fixed-width font line getting cut off when viewing the resulting post.
• hwh 8y ago
  I got mixed results with a completely different approach: starting with what actually exists within a Git repository (i.e. roughly: focusing on aspects of the plumbing layer first). However, this only works with people who can make the mental leap to be able to deduce knowledge of what should be from knowledge about what is. In the end, I concluded it's a bit like teaching cooking. There are those folks who need to be taught about full recipes and those who need to be taught about resources and corresponding steps. I have not yet seen a working approach to make both of these fractions happy, unfortunately.
• mtrn 8y ago
  I once taught[1] the building blocks of git (basically bullet time view of a commit) and people found it a bit too theoretical - even though it contained all the elements, that helped me to understand and appreciate the simplicity. There is a point, where you go from memorization (add, push, commit) to deduction (graph, objects and refs) but when this point is reached, depends on many individual factors. [1] https://git.io/fhWxg https://git.io/fhWxg
• Wehrdo 8y ago
  When I was first learning git, I found an online visualizer like this [0] that really helped make make concrete the ideas of git history being a graph, and what different operations did on that graph. There was still obviously the issue of memorizing the commands, but at least I knew what the commands were doing on a deeper level. [0] https://learngitbranching.js.org/ https://learngitbranching.js.org/
  • collyw 8y ago
    The other problem I find in git is that there are many GUI interfaces and none of them are consistent. In Eclipse I had a different interface depending on what project I opened, despite both the projects being in Python.
• jstimpfle 8y ago
  I found this very helpful: http://eagain.net/articles/git-for-computer-scientists/ http://eagain.net/articles/git-for-computer-scientists/. Git's data structures are well designed. Once you have internalized them, you will be better equipped to navigate through the jungle of command-line options. To understand the data structures interactively, use "git cat-file -p HEAD" and continue drilling down to an individual file in a subdirectory with "git cat-file -p OBJECTHASH"
  • jejones3141 8y ago
    I've never had to understand the internals of a web browser or text editor in order to use it; drivers ed courses don't start with a discussion of thermodynamics. Why should it be necessary for git?
    • JoeAltmaier 8y ago
      Because every source management tool has a model, and to use it at all you need to know the model. Else you're jabbing buttons and turning dials on a complex machine and the outcome is going to be tragic.
      • oblio 8y ago
        I've used SVN reasonably well without knowing its internal model. I kind of knew a bit about it, I'd never call myself an SVN expert and I still managed to do my job efficiently. Git fails majorly in this regard.
        • jstimpfle 8y ago
          git is much more powerful. It gives you control to manipulate the repository like say, a relational database. If svn is enough for you, that's fine.
          • oblio 8y ago
            > It gives you control to manipulate the repository like say, a relational database And how many people do that? Not that many. This angle is a bit like the guy who said that he doesn't want Unix file names to be UTF-8 text-only, because he crafted a sort of relational database on top of a Unix FS and by having file names be just text he couldn't do some super niche trickery. I think it was in response to this article: https://dwheeler.com/essays/fixing-unix-linux-filenames.html https://dwheeler.com/essays/fixing-unix-linux-filenames.html > If svn is enough for you, that's fine. It is, but every job these days forces you to use git. And most places I've worked at, git is used as a glorified SVN where people just have a 2-step commit to a remote server.
• unmole 8y ago
  I found teaching Git to someone unfamiliar with any other VCS was far easier than teaching someone who already knew SVN.
• Sir_Cmpwn 8y ago
  I disagree with this idea. The best way to learn git is to read the git book, in this order: chapters 1, 10, 2, 3, and the rest at your discretion. This way teaches you about the internals first, and if you understand the internals the rest of git is pretty intuitive. https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
  • collyw 8y ago
    That's a lot of reading for a tool that should be making life easier.
    • Sir_Cmpwn 8y ago
      It's an engineering tool. You'll be using it all day every day for the rest of your career, the investment is worth it.
      • 0xffff2 8y ago
        That's simply not true for many Git users. I'm a developer, so I do use Git every day, but I work with a bunch of researchers that absolutely do not need to use Git more than once a week at most. Convincing those people to care enough to learn the internals has been a constant uphill battle for me.
      • pjmlp 8y ago
        I will save this answer for when anyone complaints about C++ or Rust being complex languages.
        • Sir_Cmpwn 8y ago
          How about now :) Rust and C++ are complicated languages, and that's bad. But git isn't complicated. Git is a handful of simple ideas composed in interesting ways. It looks complicated because there's a lot of porcelain commands with a lot of options, but all of them are just manipulating the same simple internals which, once understood, are clear and intuitive.
• black-tea 8y ago
  The best way to learn git is to learn what's happening at the DAG level. That way you can think about what should happen on the DAG and then think of how you can use git to achieve that. For example, a fast-forward merge and a reset can be used to achieve the same thing. It's also very important to learn to use the reflog. When I was learning to climb they told me I'd never get really good until I'd fallen once. The same thing goes for git. People are really scared of it because they think they could lose work or something. Thanks to the reflog and the way git works, that's actually quite difficult to do.
  • e3b0c 8y ago
    I learned that Git stores data as DAG at the very beginning when introduced to it. But I came to get clicked until I realized that it is not only a DAG but an immutable one. That is, existing nodes of the DAG are never changed once created. The only operation supported by the system is more or less: create. Also, using the plumbings to peek into the content of the objects and refs inside the .git helps a lot as well.
    • black-tea 8y ago
      Yeah, that's a very important point. Even changing the parent of a commit, that is, an edge in the graph, changes the hash of the commit. Therefore to change the parent (like in a rebase) you have to make a new commit, but the old commit doesn't go anywhere, you just can't see it because you have no reference to it any more. Git will garbage collect these commits that can't be reached by any reference after a while, but usually that's long after you've forgotten they ever existed.
• kyancey 8y ago
  Better yet, don't. Just use something decent like fossil or mercurial.
• avar 8y ago
  I contribute to git, if anyone's got any UI warts they're bothered by in particular I'd love to hear about them. Maybe it's something we can fix.
  • pletnes 8y ago
    LFS works by installing hooks. This prevents me from adding my own. Also the one-hook-only policy makes it harder to share hooks.
    • avar 8y ago
      Yeah this would be great. I started working on adding support for <hook>.d/* in addition to <hook> a couple of years ago, that got to a proof-of-concept stage, but some of the long tail is hard to handle so I dropped it, but it could be finished. There was also a disagreement about what the semantics should be, e.g pre-receive.d/* hooks failing on the first one that failed in glob() order or not, which has implications for whether they can run in parallel. The bit that stuck from those patches was being able to configure the the core.hooksPath variable to a hook path, which sometimes can with some stretching fulfill some of the use-cases, but most users end up with a meta-hook runner of some sort.
      • pletnes 8y ago
        Glob() is (iirc) not sorted in any way on macos. I would prefer alphanumerical sort by name as it is stable across OSs. Parallelization is optimization so I think «make it right, then make it fast» is sound advice.
        • avar 8y ago
          The glob() function is sorted consistently on all platforms. It's mandated by POSIX[1], and from the OSX docs I could find[2] sorted unless you specify the POSIX GLOB_NOSORT flag, as on other platforms. In any case, even if glob() wasn't portable it's easy to provide an API compatibility layer that's just readdir() + qsort(). That part would be trivial, and might perhaps be needed due to collation issues in the sort. Doing it in parallel (preferably in a random order) isn't just an optimization, but would ensure that there isn't an implicit dependency on whatever iterative interface we'd first ship with. 1. http://pubs.opengroup.org/onlinepubs/009695299/functions/glob.html http://pubs.opengroup.org/onlinepubs/009695299/functions/glo... 2. https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/glob.3.html https://developer.apple.com/library/archive/documentation/Sy...
• ionmonkey 8y ago
  For anyone looking for resources on teaching git I'd recommend the software carpentries - all open source with a great community behind it. http://swcarpentry.github.io/git-novice/ http://swcarpentry.github.io/git-novice/
• zwischenzug 8y ago
  'How to teach Git' was something I had to think a lot about when a lot of my technical colleagues didn't know what a rebase was, and asked me to sort out their 12-team merge history (the 'git log --graph --oneline' spanned the width of multiple pages before you could see any commit message at all). I realised that there's a point you can't progress beyond with git without having to do some thinking and learning. And lots of people aren't interested in the theory behind distributed file content. So I took Zed Shaw's hard way method and applied it to git. It made for a really enjoyable course at work and I then turned it into a book (1). The tl;dr is I believe you need real world experience with a mentor prodding you at the appropriate time to think a bit deeper. Then the understanding will follow. Here's an example from an 'advanced' chapter: https://zwischenzugs.com/2019/01/09/git-hooks-the-hard-way/ https://zwischenzugs.com/2019/01/09/git-hooks-the-hard-way/ [1] https://leanpub.com/learngitthehardway https://leanpub.com/learngitthehardway
• sramsay 8y ago
  Years ago, I tried to teach git to my (college) students, and it was a complete disaster. Like a lot of technical things, it's easy to get them totally confused with a single off-the-cuff sentence (and to be honest, I think I underestimated how difficult it would be to explain it and the kinds of pain points they'd encounter). Reading this article, it occurs to me how useful the idea of a "staging area" would be to helping them understand. I don't think of it that way myself when I'm working with it (I suppose I do, but not in those precise terms). But looking back, that's what was tripping them up. If you're just talking about local and remote repositories, you're not really giving them the right idea of the workflow.
• Jach 8y ago
  Git itself is so simple, it's all the stuff around it that can be overwhelming. Social mores about all the possible workflows are maybe the biggest (rebasing vs merging, granularity of branches and their longevity, acceptance of partial commits reflecting a state never realized in isolation on disk, commit hooks, requirement of every commit to satisfy properties x,y,z, direct access to common parent repo copy vs requiring some sort of pull request flow (and dependence on github and all their stuff)) but there's also work tracking, code review, build automation, test automation, deploy automation...
• navinsylvester 8y ago
  No one is appreciating the effort and a different take here. Let me congratulate the author on job well done. There are people who love illustrated explanation and for those these are perfect. This is just meant as a template which others can use to build the illustrated material and in no way a comprehensive git tutorial.
  • e40 8y ago
    I completely agree. I've seen a lot of these, and this one is simple, to the point and easy to understand.
  • max23_ 8y ago
    Agree, I think this is sort of like a very simple introductory on what git is about and to me it does the job.
• billpg 8y ago
  Shameless plug: "GIT isn't perfect, and other blasphemies." https://blog.hackensplat.com/2018/12/git-isnt-perfect-and-other-blasphemies.html https://blog.hackensplat.com/2018/12/git-isnt-perfect-and-ot... (Addresses some of the points raised in this article.)
• ahartmetz 8y ago
  And here is something to take the garbage quality of Git manpages with some humor https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/ "git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"
  • pferde 8y ago
    Thank you for this, it made my day. :)
  • philbarr 8y ago
    That's fantastic!
  • arduinomancer 8y ago
    That's hilarious
  • mrzool 8y ago
    Nothing short of sublime. Thanks for sharing.
  • romwell 8y ago
    This is a kind of very specific, targeted, niche comedy, excellently executed. I only use Git casually, and I can't tell how much of that text couldn't make sense in an actual doc; it all looked real enough at a glance. Thank you for sharing, this made my week.
  • zwieback 8y ago
    Love it. I'm sold on git but it often feels like I'm in one of those man pages.
    • LyndsySimon 8y ago
      In my experience, it gets better. After a while you know everything you need to not only do your job, but to understand and resolve common issues. After a couple of years you'll be at the point where the only time you have to dig through manpages is when you're trying to do something esoteric or clever.
• hashhar 8y ago
  I feel that Atlassian's git tutorial is the best I have come across so far. https://www.atlassian.com/git/tutorials https://www.atlassian.com/git/tutorials
• motivated_gear 8y ago
  I like the painting analogy and have used it frequently. Let's say you were commissioned to create a landscape painting. It'll be a big payday if you get it right and its due in 30 days. Because you know you can make mistakes, you make a photo copy of your work every day and make a stack of them neatly on your desk. This photo copier is really high quality as copies are made at the molecular level. On day 16, you find yourself working on the mountains in the picture. You sneeze and Oh no! You got paint all over your work. But since you have your copy pile, you just make another copy of day 15 and keep going. But lets say you think its a lot and want a friend to work on the painting too. Just allow her to copy your latest photocopy and you both are off to the races! Git seems complex but when you bring it down to a practical, non technical level, beginners pick it up faster :)
• Fellshard 8y ago
  Humbly, I'd disagree that's the best, though this is a superb _part_ of the picture to teach Git well. These are nearly the last steps, I would say. When new colleagues joined our firm and hadn't yet learned Git, the problems were always the same: uncertainty. They didn't know which Git operations were safe, and they didn't understand how to perform seemingly risky maneuvers with zero risk. They're used to even more dangerous tools that can wipe your work in a second - and, to be fair, Git can as well. The difference is that once you understand Git, you never have to worry about losing work. So the way I would teach Git is to honestly start with the graph. Show it in action with pictures. Show how to always keep references to commits around to ensure work sticks around. Show how branching and stashing work, let them be confident that the tool will keep everything right where you left it. _Then_, once they're confident in the basics, weave in the remote repositories.
  • epage 8y ago
    > So the way I would teach Git is to honestly start with the graph. Show it in action with pictures. Show how to always keep references to commits around to ensure work sticks around. Show how branching and stashing work, let them be confident that the tool will keep everything right where you left it. Personally, I think this should be coupled with teaching `git reflog` as the universal undo (as long as they don't `gc`).
    • hinkley 8y ago
      Don't teach anybody git gc. The people who really need to find it will come upon it all on their own.
• syntaxing 8y ago
  This is a pretty great overview! However, I learned Git and Github from Udacity's free course [1] and it was amazing to me since I am more of a visual learner. It got me up and running with Git within a week or two. I recommend others who have no prior experience with Git to check it out. [1] https://www.udacity.com/course/how-to-use-git-and-github--ud775# https://www.udacity.com/course/how-to-use-git-and-github--ud...
• mdpopescu 8y ago
  1. Install TortoiseGit 2. Use Visual Studio to commit (it automatically does "git add" with the new files you added to the project - I always forget to do this manually) 3. Use TortoiseGit to do "git push", because Visual Studio has a problem with ssh keys (or at least had a while ago and I didn't bother to check since) 4. When something breaks (and it will), google like crazy until you find a solution There. I never needed more in a number of companies. [Yes, somewhat tongue-in-cheek and of course limited to people who use Windows and Visual Studio, but I have discovered that's a significant number.]
  • mazlix 8y ago
    Yeah that's probably a good bare minimum amount of git knowledge. But I feel like that's making git which can be a super helpful and powerful tool nothing more than a means to an end. Learning the functionality of git can really help you out. For example, I almost always use the `-p` flag (particularly `git add -p` which gives me a chance to manually see every change I've made, often I'll find some junk that I may have left somewhere else. Also being familiar with how to rebase series of commits onto and off of other branches can be a huge time saver.
    • wtetzner 8y ago
      > But I feel like that's making git which can be a super helpful and powerful tool nothing more than a means to an end. It also feels like a clunkier workflow than just using git from the command line. It's probably easier to get started that way, but learning the basics of git from the command line isn't too hard.
  • cwbrandsma 8y ago
    I've found the Visual Studio git integration to be not good with large solutions, just slows everything down. So I have it disabled in my projects. What I do: I use GitHub desktop to get everything configured, then use the PowerShell command line to do all my work. Merge conflicts are fixed with VS Code.
  • mcguire 8y ago
    "...it automatically does "git add" with the new files you added to the project..." Uh, yeah. You don't add random temporary files (notes, temporary testing data, the florist's phone number that you'll need after the meeting you're already late for) to your projects?
• daosyn 8y ago
  Just yesterday I attempted to explain to my colleagues (who have been mainframe developers all their life) the concept of having multiple remote repositories and different possible setups. I think I explained adding remote repositories well enough, and mentioned the use cases for such a setup -- having only read access from a repository and needing to develop in a fork while keeping up to date with the original. Does anyone have a good analogy for this? I think they understood for the most part, but explaining things better is something I have been really trying to improve on in the workplace lately.
  • someguy101010 8y ago
    I really think showing them how it works visually with a DAG is a great way to show someone how git works. Also, Linus has a great talk about git and how it works here: https://m.youtube.com/watch?v=4XpnKHJAok8 https://m.youtube.com/watch?v=4XpnKHJAok8 (Sorry for mobile link, I'm on my phone RN)
• allenu 8y ago
  I gave a git talk at work recently and what I found works was teach the graph from the beginning. This includes a lot of diagrams of what the graph looks like as you commit and branch: - show what happens as you add commits to a branch - show that branches are just pointers to commits - show what creating new branches looks like, i.e. creating a new pointer - show what merging looks like (a new merge commit is added, or else fast-forward merge and that the branch pointer just moves) - show what happens if you don't rebase (i.e. "ugly" non-linear graph) ... then teach what rebasing does (i.e. creates new nodes and moves the pointer) I found that building up from the ground up and illustrating graphs allowed people to conceptualize things much better. There was still some confusion once merging was introduced (what happens to those earlier commits? do we need them?) and mostly because people hadn't thought of the graph before. Git is one of those tools where you can totally do your job just by knowing the basic commands but not really know what is happening under the surface, which I think is a testament to the tool. But, that leads people to conceptualize their own idea of what is going on... and getting it wrong and being confused when they want to do something outside of their basic toolset.
  • da_chicken 8y ago
    Yeah, it was definitely a set of images [0] that made git click for me, but even those are not necessarily the best pictures to use. Git's mental model is basically: > Ok, what if we took our SVN repository and the first thing we did was check in an SVN repository to that. So now you check out the repository, and you get a complete local repository that you can do anything you want with! > So Pull/Push are the terms we use for the check out and commit of your local repository to the remote repository, and then Checkout/Commit works from your local repository just like you're used to with SVN. And the real magic is what they did by building a system on top of this model to let you merge changes all the way up while looking at the code like you'd expect you'd need to. The problem is that git's toolchain still feels arcane to use, and it requires that you have good working knowledge of the underlying models. It's confusing enough that you can't function unless you have that because you don't know where you are or where you're going. It's a fantastic tool, but it's like driving a car with two steering wheels, two gear shifters, and six pedals. Then you say to yourself, "How do I get to the market, buy some milk, and come right home?" and your brain starts to melt a little bit. You shouldn't need to know the nitty gritty of how git works internally just to get it to work right any more than you should need to know how a disk works in order use a file system, but over and over we keep seeing that knowing that is really the only way to use the tool correctly and that it takes quite awhile for people to get. [0]: https://blog.osteele.com/2008/05/my-git-workflow/ https://blog.osteele.com/2008/05/my-git-workflow/
• mandeepj 8y ago
  I really like these two resources for learning git http://ndpsoftware.com/git-cheatsheet.html#loc=workspace; http://ndpsoftware.com/git-cheatsheet.html#loc=workspace; Guided tour - http://gitimmersion.com/ http://gitimmersion.com/
• iheartpotatoes 8y ago
  This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)
  • akulbe 8y ago
    This is so so fitting, and describe me to a "T" as well. I'd add oh-crap-I-screwed-up-so-let's-clone-the-repo-and-start-over to the list.
    • smichel17 8y ago
      What can you screw up that requires re-cloning the repo rather than just a reset --hard?
      • akulbe 8y ago
        Not knowing about the "reset --hard" feature? :)
      • hinkley 8y ago
        For one, accidentally deleting the .git directory.
    • buovjaga 8y ago
      Alternative to nuking from orbit is taking a look at "Flight rules for git": https://github.com/k88hudson/git-flight-rules https://github.com/k88hudson/git-flight-rules
      • rachelmcarmena 8y ago
        Awesome! I'll add it to my post! Thanks!
  • sjburt 8y ago
    I think once you understand the graph, then looking at what the graph looks like and what you want it to look like usually leads you to being able to figure out what operation you want. And then git fetch/push/pull are mostly about copying parts of that graph from one place to another. After that, it's mostly a question of what workflow you want and that becomes much more than a git question because git works for a variety of workflows, and many of the features of git are really only relevant for certain flows.
• jecxjo 8y ago
  I like the diagrams, as many explanations often skip the staging portion of the whole git process. I use that so much that it baffles me that most people skip it. Then again, I typically don't like having tons of "WIP" commits so I stage a lot and if I need to switch to another branch I'll commit a WIP that I quickly `rebase -i` to get back to a clean status. As for the teaching part, I have found the best results by having you and the learner actually "working" on the project at the same time on your own machines both pushing to a centralized server. It becomes too easy to go over all the commands and feel like you understand it. Most of the scary parts of git are used when its multiple developers on the same project. And oddly enough, having the learner do both Developer A and Developer B's tasks don't seem to work as well as having the learner just do Developer B while I do Developer A. Trying to explain to someone when to use merge, when to rebase, and when to use cherry-picking to get the code I just pushed into their current working branch can be done so much easier when its hands on AND knowing exactly who is doing what steps.
• Walkman 8y ago
  This is very good explanation, but only explains what happens with the files, nothing about the graph what is a git repository. This talk helped me tremendously to finally understand what's going on in git: https://www.youtube.com/watch?v=1ffBJ4sVUb4 https://www.youtube.com/watch?v=1ffBJ4sVUb4 It is one of the best talks about git for beginners with an unfortunate title :D Also, this interactive visual tool helped me to understand branching: https://learngitbranching.js.org/ https://learngitbranching.js.org/
• Animats 8y ago
  From the article: "If you take care the commit history, consider the use of git pull --rebase. Instead of fetch + merge, it consists of fetch + rebase. Your local commits will be replayed and you won’t see the known diamond shape in commit history." No, not how to teach Git. Open source just can't do good user interfaces. The result is almost always a zillion features in search of an architecture. Blender managed to almost dig itself out of that hole, but it took over a decade. Gimp is still down in the pit.
  • sephoric 8y ago
    I was just running into this dichotomy this morning. To test my app Autumn on High Sierra, I had to install it in a VM, so I tried VirtualBox (open source) and Parallels Desktop Lite (in-app purchases). Not only did Parallels have a smoother, cleaner, more modern and easier GUI, VirtualBox just out-right doesn't work when trying to install High Sierra, and I had to find third-party instructions online just to bypass this bug. Plus it likes to crash right after shutting down the VM. I'm not really sure if there's some deeper philosophical reason behind this dichotomy, but I've seen it hold true for a lot of apps and their open source alternatives, and many people have said the same thing holds true about my app Autumn and open source alternatives like Hammerspoon and Mjolnir. As a rule, we really do seem to get what we pay for.
    • y4mi 8y ago
      You're pinning THAT on opensource? a) VirtualBox is an oracle product. That by itself should be telling. b) High sierra is unsupported as a Guest OS in VirtualBox. You do know what that means, right? c) You seriously complain about the darth of open source virtualization for an OS, which disallows virtualization on anything but apple hardware? ...really? If you want good open source virtualization you'll want to use Qemu/KVM. Which obviously doesn't support any apple OS either, because they're not allowed to virtualize it. Take that up with Apple, not open source
      • sephoric 8y ago
        It was the most recent thing I did (literally this morning) so it was fresh in my mind. I'm also not an expert in virtualization solutions given how I haven't needed to use it until now. But this has held true for many, many apps and their open source alternatives. Paid products generally tend to be higher quality than open source, for whatever reason.
• rhwelc 8y ago
  I've had to teach git to several people. Here is what i teach: - never force push (with exceptions) - don't use reset (with exceptions) - don't commit to master - stop immediately if git tells you, you have 200 changes Aside from that, people don't really seem to have trouble. Git is pretty functional with just add, commit, push, pull. People learn more commands as they need them. This post was humor
  • Accacin 8y ago
    Hahah, once at work a guy force pushed to a branch that was just about to be merged. This almost resulted in some guys work being lost but luckily it was recovered. This was immediately followed by another dev writing 'DO NOT FORCE PUSH' on a post-it and sticking it to his monitor :D Edit: I meant merged not committed.
• jmmcd 8y ago
  I applaud this effort, but it's still not hitting the right notes, eg: > how to show the changes of a file in the staging area: git diff --staged Ok, but this shows the diff against what: the file in the working directory, the file in the local repo, or the file in the remote repo?
  • jononor 8y ago
    Agreed that this is lacking. Staged is what will be included in the next commit (as made by git commit). So it is a diff against HEAD (current commit). Also, it does not show a particular file, but all the changes in the staging area. To show only one file have to do `git diff --staged -- src/myfile.c`
• vngzs 8y ago
  This is missing pointing everyone at a phenomenal ncurses git log viewer: https://github.com/jonas/tig https://github.com/jonas/tig And another great bit: always do `git commit -v` for verbose commit edits. Read your diffs before you commit them.
  • deanCommie 8y ago
    How can anyone have a project home page without..showing me why I should use the project. Would it have killed Jonas to include a screenshot in the README? I'm not going to install something just because someone says it's good. I have to go multiple links deep to get taken to a Flickr gallery, and even then I'm not sure what is so good about it: https://www.flickr.com/photos/jonasfonseca/sets/72157614470764617 https://www.flickr.com/photos/jonasfonseca/sets/721576144707...
    • vngzs 8y ago
      You make a good point, and I was similarly disappointed in the homepage, so let me elaborate a bit on why I use it: 1. I want a Git log viewer right in my terminal, that gives me most of the benefits of visualizing a Git log like a "real" GUI. 2. Fast startup. I work in dozens of Git repositories a day, many submodules, etc. To visualize these effectively, I want to type a few characters in my terminal and see the Git history in a digestible way. 3. This essentially `git log --graph --pretty` with the ability to deep-dive into a single commit view of `git log -p` with nothing more than a stroke of the return key. To exit, I hit ESC. 4. Vim-like bindings in a Git viewer. Every visual app that I use daily in my terminal has "roughly Vim" bindings, from Emacs (https://github.com/emacs-evil/evil https://github.com/emacs-evil/evil) to Zsh (bindkey -v) to Tig. 5. This is just as fast to start as `git log --graph --oneline`, but I get a fully interactive view of a Git Repo history. For example, the Linux source [1]. Perhaps I should compile my thoughts and send some README updates and screenshots to help the project. [1]: https://i.imgur.com/yd7cSd1.jpg https://i.imgur.com/yd7cSd1.jpg
• deleted 8y ago
  [deleted]
• darekkay 8y ago
  I agree with the author - many developers learn git (or version control in general) along the way, even though it's a fundamental skill needed for almost every project out there. This leads to insecurities, inefficencies and wasted time when (not if) something breaks. That's why our company training for new graduate hires consists - among others - of 2 days of git/github training. I love git (even though I might experience some sort of Stockholm syndrome), and while it's the most popular VCS, it is not an easy tool to learn and should not be condensed into "commit - pull - push - now start working on some tickets".
• hashkb 8y ago
  Many developers view git (and other "helper" tools like text editors, linters, grep, SQL, ... everything but their programming language) as second-class citizens. The way to teach these tools is to make them primary citizens in your company culture. Emphasize that, without a strong grasp on a variety of important tools, devs will be unable to perform at or above the bar. Don't promote anyone to "senior" engineer who can't easily show the benefits of these tools while a junior engineer pairs with them. Otherwise, developers will teach themselves the absolute bare minimum necessary to get their jobs done and go home. The quality of the training materials is of minimal importance. I learned git because I wanted to be better at it.
• QML 8y ago
  As unorthodox as it is, the way I learned Git was through re-implementing it as a project for the data structures course I was taking [1]. This isn't the method I would entirely recommend to most people: instead, like the author, make a diagram for each of the (most-used/basic) commands and sketch out how they interact with the data structures. [2] is a good starting point. [1] https://inst.eecs.berkeley.edu/~cs61b/fa17/materials/proj/proj3/index.html https://inst.eecs.berkeley.edu/~cs61b/fa17/materials/proj/pr... [2] https://git-scm.com/ https://git-scm.com/
• Derbasti 8y ago
  I have taught git for university classes for some years. To be honest, git is a mess. It is conceptually not that hard, but the nomenclature is inconsistent and dangerously ambiguous (quick, what is the difference between reset, rebase, revert, and checkout?). The most effective work flow I have found so far, is teaching only status/clone/pull/add/commit/push. Show them explicitly what happens normally, what happens when two changes conflict, and how to resolve merge conflicts. Using git on the command line only. Then, have the students use git for a big-ish multi-student project. They will figure out the workflow themselves. After that project, once they understand the basics, you can talk about branches, debasing, the log and reflog, pull requests, and all the rest. Don't introduce graphical front ends before this point. This method works well. It takes about one hour of teaching, and five weeks of active use afterwards. Git is a total pain to learn, and can only be understood by actively using it. I often get very positive feedback for having taught git. I have gone through a few iterations with this topic, and have found that stripping down the initial instructions to an absolute minimum works best. All those fancy box diagrams are actively harmful to beginners.
  • maceurt 8y ago
    I don't know if this is true. For me personally I have had to use git for a lot of different projects, but I still don't understand anything besides commit, push, pull, add, and force-push (lol). In my experience you can get away with just learning those commands, but I still don't feel comfortable with git.
    • marssaxman 8y ago
      Does anyone really feel comfortable with git? I've been using it for over a decade, in a handful of different organizations, on projects large and small, both at work and for personal projects, and it still feels like a convoluted mess. Its terminology is wildly inconsistent and my mental model of its behavior remains stubbornly full of fog. I have a library of recipes committed to memory, but I still don't really understand it, and sorting out what's gone wrong when things inevitably go wrong remains challenging.
  • probinso 8y ago
• jbergens 8y ago
  I think it is easiest to show a graphical UI like SourceTree or GitKraken when you explain git. GitKraken is my favourite but it costs a little money to use at work.
• gerbilly 8y ago
  It would be so much easier to use git if there was simply a "git undo" that would cleanly undo the last git command (or last n commands would be even better). Then you could learn more easily via exploration and experimentation. And I do mean just one command to undo all the things, I know that you can undo a lot of things in git but each command is different, and I know that undoing pushes is hard.
• cben 8y ago
  I only have a sample of 1 (my wife) but I've found Ungit: https://github.com/FredrikNoren/ungit https://github.com/FredrikNoren/ungit unparalleled for explaining the graph model behind git — what's a merge, what it means to fetch vs pull, what's the difference between committing locally vs push etc... The specific points that make it great for such teaching: 1. pretty graph 2. hovering over actions such as Commit / Merge / Rebase / Push shows what would happen to the graph if you do it. 3. you can manually "Move" local & remote branches anywhere you want! This is mildly risky as a habit, but much clearer to explain than fast-forward and push, especially with multiple remotes. 4. automatic fetch that works pretty well (though explicit fetch UI with multiple remotes is clunky). For people scared of merging and conflicts, it's liberating to teach "fetch is always safe" and "local commit is always safe", and that you can fast-forward or merge/rebase separate step.