https://www.garyrobinson.net/2014/10/git-in-two-minutes-for-a-solo-developer.html Gary Robinson's Rants Rants on Python, crypto, politics, music, and other assorted stuff. * Home * Archives * Profile * Subscribe << There are 10 kinds of people in the world... | Main | LIGO's Discovery of Gravitational Waves >> October 21, 2014 Git In Two Minutes (for a solo developer) Inspired by "Git in 5 Minutes", I decided to take things a step further, and create guide for git that takes even less time to get through. Of course, this is very minimalistic git! But it's enough be useful for beginning solo developers, and provides a start from which you can grow. As far as I know, this post is the absolute record for minimalistic git guides on the web! In two minutes, there isn't time to worry about a remote server, so this manner of using git is only appropriate for a solo developer who has a regular backup strategy in place for their hard drive. With 2-minute git, plus a backup strategy, you can confidently commit files and know that you can see changes or restore an earlier version if you need to. Why does this even matter? Well, one of the most annoying and time-consuming experiences a developer can have is to realize that something that used to work no longer does. In such situations, simply being able to see changes and go back to an earlier version can be a huge help. Also, being able to go back gives you freedom to experiment with a new approach -- there's no problem experimenting because you can always go back. When you have a chance, you should definitely learn about such features as staging and branching, and pushing and pulling to/from remote repositories. But what you'll learn here will still be useful! Note: When a filename is mentioned below, you can just as easily use a file path. Getting set up to use git We're assuming you're working in a directory. The first thing you should do is: git init which initializes the directory for git use. Telling git about your files Now you have to tell git which files it should care about. If you have N files, you can do git add ... to add them. Or if you want to add every file in the directory, you can do git add . Committing changes Next, we need to commit changes. Any time you want to commit changes to one or more files, do git commit ... -m "This is your commit message" Or, to commit all files that have changed since the last commit: git commit -a -m "This is your commit message for all changed files" Be sure to make your commit message contain enough of a description that you can figure out what version you want to go back to. Viewing history Now we need a way to see old versions are available. To see your commit messages along with each version's "hash" (a number that refers to the version), you can use the following command to show them in a one-version-per-line output. git log --pretty=oneline That will give you output that looks like the following, showing each commit's hash together with its commit message dbe28a0a1eba45d823d309cc3659069fc16297e3 4th version I wanted to commit 13bbf385e6d1f94c7f11a4cdfa2a7688dfdd84f8 3rd a1696f671fb90dc8ea34645a6f851d0ab0152fc2 2nd version 179e59467039c7a7b81f676297415c8e018542a0 first version Note, you can also use git log for a much more verbose output, with multiple lines per version, and you can use git log --pretty=oneline -- to view only the changes for a particular file. (Note the space after the second pair of dashes!) Restoring an old version To restore a file to an earlier version, you need to identify the version you want to restore. To restore the most recently committed version, just do: git checkout HEAD -- To get back an earlier version, just use the first few characters of the hash (enough to uniquely distinguish it): git checkout -- For example, git checkout 179e59467039 -- myfile will revert my file to the contents of the file called myfile that are associated with the 179e59467039c7a7b81f676297415c8e018542a0 hash (in this case, the first committed version of the file). Seeing changes You usually won't want to retrieve an old version of a file without first examining the changes it contains! To see a list of the changes between the current file and the most recently committed one, you use the fact that HEAD represents the most recent commit: git diff HEAD -- Alternatively, see a list of differences between the current version of a file and a historical one, you refer to the historical version's hash: git diff -- You can also compare two historical versions: git diff -- Finally, to see a list of the changes you've made since your last commit across all files, simply do: git diff Note: all the diff variants shown above put the results into a pager. You can page through using the space bar, and quit with q. If you don't want to use the pager, add -P, like: git -P diff HEAD -- Undoing a bad commit More often than I care to admit, I've committed a change and then found that there was an error in either the commit message or in the code itself. I don't see any need to keep that error for posterity. So here's how to undo it: git reset HEAD^ One more thing - optional - may add another minute While you can get a lot of benefit using just the features above, here's one more thing you'll find to be useful. If you don't want to bother with it now, don't - try it another time. Sometimes, you're not sure what files have changed. To find out, you can do: git status That'll generate a list of files and their statuses. For example, a file that hasn't been "git add"-ed will be listed as untracked; if it's a file you care about, you should add it. The reason I consider this command "optional" in a two-minute guide is that it can be a little unwieldy. It can list a lot of files you don't care about. For instance, if you're programming in Python, it'll show the compiled .pyc files that Python generates. And you'll probably want to do something about that. To fix it, you need to create a file called .gitignore in your project directory. For instance, if you're working on a project in Python 2.x, you'll probably want it to contain (at least): .pyc Notice that .gitignore understands the * wildcard. And if you want to hide an entire directory, you append the folder name with a slash. For instance you're working in Python 3.x, the compiled files go in a directory called __pycache__, so you'll want the following in your .gitignore: __pycache__/ And that's it! Just keep this guide handy. That's all you need to know to get started with git, as long as you have a regular backup strategy for your hard drive. If you don't want to memorize anything, just keep this guide bookmarked and you'll be able to commit, compare versions, and get back old versions without any trouble! Remember, this guide is literally as minimalistic as you can possibly get in order to do something useful with git. For powerful features like branching, staging, and sharing with others via a remote server, be sure to move on to Git In Five Minutes and even (?!) longer git guides when you have a chance! [Update Aug 6, 2022: added the entry for undoing a commit. Update Jan 2, 2017: added the use of HEAD in restoring file versions. Update September 7, 2015: added two more ways of seeing changes. Update September 20, 2015: for some reason the optional section on git status and .gitignore disappeared at some point. So I put it back! Also rewrote the diff section to put the HEAD version first.] Posted at 05:07 PM in Web/Tech | Permalink Reblog (0) Comments Derek Hi Gary, I just wanted to say that I think this is possibly the clearest, most concise introduction to git that I've seen. No mucking around discussing DAGs and and branching and repos and stuff, just how to get the massive benefit of version control with a few easy commands. Well done, and thanks! Posted by: Derek | October 23, 2014 at 12:05 AM Mitch I've never done "git commit file -m ..." I have only ever done "git add file" (or "git add -A"), review status, then "git commit -m ..." I think that part of your tutorial is a little unclear, since the file name is not necessary after the add is already done. Posted by: Mitch | October 23, 2014 at 01:56 PM javdramos This is exactly what I needed to start with git. Thank you! Posted by: javdramos | October 23, 2014 at 11:09 PM Dan In your writeup please include the git!s purpose and and why you'd want to use it. In addition add na continuing example in each section. All this would make everything much more understandable. Dr. Dan Posted by: Dan | October 24, 2014 at 12:22 AM Gary Robinson @mitch: What I'm going for in this tutorial is to not require the developer to understand staging. I'm framing "git add" as the way to make git aware of a file. After that, he doesn't do 'git add' again for the file. He just does 'git commit -m "message" when he wants to commit that file'. Or he can do 'git commit -a -m "message"' and commit only the changed files. I don't think there's anything wrong with staging, obviously; it's just something I think it unnecessary for getting started with git if you're trying to do so in the simplest possible manner. I do mention it in the text as something to learn about later. Posted by: Gary Robinson | October 26, 2014 at 10:40 AM Gary Robinson @Dr. Dan: The text does say why the developer should want to use the subset of git that is presented here. It doesn't explain why he'd want to use larger subsets of git (including staging, branching, etc.) because it doesn't teach them. Someone who is a rank beginner isn't going to have an intuitive feel for why things like branching and staging might be useful, even if I gave an introduction to them (which would have to be short enough to not violate the 2-minute goal of the tutorial). So, I'm leaving them out. In time, the developer may start working with other people, who will probably already be using git, and he can learn about them at that time. At least he'll already be comfortable with this subset of git, which will give him a leg up at that time. Posted by: Gary Robinson | October 26, 2014 at 10:44 AM John think you! Posted by: John | November 03, 2014 at 09:02 PM Verify your Comment Previewing your Comment Posted by: | This is only a preview. Your comment has not yet been posted. [ Post ] [ Edit ] Working... Your comment could not be posted. Error type: Your comment has been posted. Post another comment The letters and numbers you entered did not match the image. Please try again. As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments. Having trouble reading this image? View an alternate. [ ] [ ] [ ] [ Continue ] Working... Post a comment Comment below or sign in with Typepad Facebook Twitterand more... You are currently signed in as (nobody). Sign Out [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] (You can use HTML tags like and
    to style your text.) Your Information (Name and email address are required. Email address will not be displayed with the comment.) [Name ] Name is required to post a comment [Email Address ] Please enter a valid email address [Web Site URL ] Invalid URL [ Post ] [ Preview ] Working... Please enable JavaScript if you would like to comment on this blog. About [feed-icon1] Subscribe [feed-icon1] Subscribe (Only Python posts) Search [ ] [Search] Archives * July 2022 * June 2022 * July 2021 * April 2021 * April 2020 * February 2020 * November 2017 * March 2016 * February 2016 * October 2014 Categories * Current Affairs (49) * Durandal (1) * Music (101) * Python (10) * ReasonML (1) * Science (32) * Web/Tech (186) See More Recent Comments * Hellmut Weber on Non-blocking raw_input for Python * Gary Robinson on The Wild World of NFTs * Gary Robinson on The Wild World of NFTs * Gary Robinson on The Wild World of NFTs * Gary Robinson on The Wild World of NFTs * Gary Robinson on Bertrand Russell proves he's the pope * sri on Bertrand Russell proves he's the pope * sri on The Wild World of NFTs * Gary Robinson on The Wild World of NFTs * sri on The Wild World of NFTs * Gary Robinson's Rants * Powered by Typepad