The first thing you need to know about Git is that it was hand-crafted by the guy that brought us Linux. Make no mistake, Git thrives in the realm of hard-core coding and is a favorite new toy among coding enthusiasts. The second thing you need to know is that Git is incredibly useful as a project management tool. I mention both Git\u2019s usefulness and the context in which it was developed because Git can be esoteric and difficult. But once you\u2019ve gotten over the learning curve, the benefits fairly leap out. This article aims to give you enough of an understanding so that you can get around Git\u2019s basic features without being overwhelmed by the more complex things it can do.Why you need version controlFirst, a rundown of the benefits, then the pain. Git is a Version Control System (VCS), which is essentially a file-sharing system tailored to manage the workflow of a team of developers. With a VCS in place you\u2019ll never overwrite files you\u2019re working on. Instead, each time you make significant changes you add them to a repository of code handled by the VCS. A detailed history of every change you\u2019ve made to the project is maintained by the VCS, giving you the ability to revert back to previous versions of the project. On collaborative projects that undergo lots of iterations, this system can save your ass. Your collaborators can even work on the same code at the same time without creating conflicts. This is possible because each member of the team works on a unique local copy of the project that is in turn merged into the shared repository. For our purposes that shared repository lives on GitHub, an online service that fosters open source collaboration by providing free hosting for coding projects.Getting StartedYou can grab both the GitHub client app and the Git shell for working on the command line from GitHub.com. In a moment I\u2019ll explain why the command line is important. Once you\u2019ve created an account on GitHub, go ahead and create your first public repository.By clicking the \u201cSetup in Windows\u201d button, you’re telling GitHub to launch your Windows client app. (Notice you’re also given instructions for creating a new repository from the command line.) A local folder is created on your system that is synced up with the online repository. This means that any changes you make to local files will automatically be recognized by your GitHub client when you fire it up. I\u2019ll show how to get your changes \u201cpushed\u201d to the shared repository, but first, a brief foray into the command line side of things.Brevity is the soul of GitI\u2019ve been leading you by the hand, now it\u2019s time to learn some jargon. Primarily you\u2019re going to be interacting with your repositories via the GitHub client, a fairly easy to use GUI, and the GitHub web site, but it\u2019s crucial that you can fall back on the command line, just in case something doesn\u2019t work. Remember, Git was made by back-end developers, for back-end developers, and will always work in that context. All of the jargon you\u2019re going to pick up has its roots in the Linux culture. Here I\u2019m viewing a list of my local repositories, or \u201crepos\u201d, from the GitHub client:If I wanted to look at a repo from the Git shell, I\u2019d navigate to the appropriate local folder and list its contents:Notice I\u2019m using the Linux commands \u201ccd\u201d to change the directory, and \u201cls\u201d to list its contents. The goal here is not necessarily to be able to create and view repositories from the command line\u2014that\u2019s easily accomplished on GitHub\u2019s web site and through the client\u2014but rather to get you comfortable enough on the command line so that you can \u201cpush\u201d updates to a repo, and \u201cpull\u201d the latest version of a project, should all else fail (Hint: It will).Adding and CommittingTo get started I\u2019ve added the file style.css to my repo simply by dragging it into the new-repo folder, where I’ve told GitHub to look. As you can see, the client app recognizes this as a new file:The yellow dialog box on the right tells you that you have \u201cuncommitted changes\u201d. By committing these changes you’ll be taking a snapshot of your staging area. You can do that through the dialog box, making sure to give it a description so you’ll remember where you were at this point in the project. Here\u2019s how to accomplish the same thing on the command line:Two other commands you\u2019ll use often are \u201ccheckout\u201d and \u201creset HEAD\u201d. Both disregard changes you\u2019ve made locally that you don\u2019t want to commit.Push ItBut you’re still not done. The last step is to \u201cpush\u201d your updates to the remote server. Usually this is a simple matter of clicking \u201cpublish\u201d in the client app and calling it a day. However, on this occasion I get a fatal error with no explanation provided by the app. When I push the commit from the command line I get an HTTP 403 error. Still a bit perplexed, but at least I can deduce that it\u2019s a permissions issue. In fact, Git uses SSH by default to track changes, so you’ll need to either fix your firewall settings or enter your GitHub credentials on the command line. The solution here is to fire up the Git Bash shell, provided in the GitHub download bundle, and enter these commands:That seemed to work… Navigating to my repo on GitHub.com, I can see the kidney stone of a file I just pushed to the server:You\u2019re not alone in thinking that it shouldn\u2019t be this painful. Chris Coyier takes a similar approach in his video tutorial entitled, \u201cLet\u2019s Suck at GitHub Together\u201d; he uses a combination of a client app and the command line, copying and pasting the commands GitHub provides, and praying for a desirable outcome, cargo cult-style.I’m your pushermanNext we\u2019re going to slightly modify our style.css file to demonstrate Git\u2019s real value: Tracking changes. The highlighted line indicates the addition we\u2019ve made. I\u2019m going to commit this and push it to GitHub by clicking \u201csync\u201d. Actually, this action simultaneously pushes my changes and pulls new stuff from the server. Oddly, the GitHub client doesn\u2019t seem to give us a more granular option. For now, this will suffice.Now we\u2019ve got two commits, or snapshots, of our project in progress:Should the need arise, you can roll back to any of these commits. This can be really useful as a troubleshooting tool, allowing you to revert back to the last working version of a project. I can also imagine a scenario where a client wants to bring back a feature that\u2019s been removed, in which case it’s a matter of digging through your commit history.Pulling your WeightWe\u2019ve added files, committed them to our local staging area, and pushed them to a repo. Pulling updates from the server should be a snap. In the context of an ongoing project it\u2019s good practice to \u201cpull\u201d changes first, ensuring that you\u2019re working with an up-to-date local copy. The GitHub client will alert you if there are files to be pulled. You may also be asked by the client to \u201cclone\u201d a local copy of the shared repo. This is essentially the same as pulling the entire repo. You can pull files from the GitHub server on the command line like so:In this instance, there\u2019s nothing new to grab.Conclusions and Further ReadingI\u2019ve introduced you to the tools you need to carry out the most common tasks. The operations that I haven\u2019t covered mostly pertain to developers experimenting with code branches on open source projects. Briefly, GitHub is a buzz-worthy VCS because it encourages developers to create break-out projects, or \u201cforks\u201d, that they can work on independently, submitting their patches to a central repo and wowing their coding buddies. There\u2019s a good chance your back-end developer friends love GitHub, and you should too. I didn\u2019t say it was easy to use, but as it gains wider adoption, from front-end developers to project managers, it will necessarily become easier to use. You\u2019ll thank yourself later.Here are a few additional resources to get you started with Git that assume you hate the command line:http:\/\/www.webdesignerdepot.com\/2009\/03\/intro-to-git-for-web-designers\/http:\/\/css-tricks.com\/video-screencasts\/101-lets-suck-at-github-together\/And two well put together guides that love the command line:http:\/\/www.alistapart.com\/articles\/get-started-with-githttp:\/\/gitimmersion.com\/index.htmlIf you’re ready for a more comprehensive technical guide, and you need to give your eyes a rest, I recommend Travis Swicegood’s Pragmatic Guide to Git from Pragmatic Bookshelf.