Git & Github (part 1)
One of the things I love about programming is that I feel like I get to see behind the scenes of things that most people take for granted. Not only that, but I am gaining the ability to change and contribute to the inner workings of the technology that affects millions of people.
My journey in programming so far has been a journey of self teaching and writing simple (and sometimes not-so-simple) programs that run in a browser or on my computer that do something. I think I became a fairly competent beginning programmer pretty quickly, but there was always a missing piece. I knew how to write code, but not how real programmers and developers actually worked. How do a bunch of lines of code in several different files, possibly on multiple computers, all come together to make something work?
After two weeks of the DaVinci Coders class, I think I have a decent understanding of how that works. Git and Github are two tools that programmers use for revision control and collaboration on projects. I’m going to walk through the steps of setting up and using git. In another post, I’ll discuss more about github.
What is Git?
Git is a distributed version control system. It is a powerful tool to ensure that as you work on, change, and update a project, you aren’t prone to lose something or break something that worked before. There are many ways to install git, and I’ll let you google to find them. Once git is installed, here’s how you use it to create a repository in a directory called git_practice.
create the directory:
change into that directory:
You now have a .git/ directory that contains the inner workings of git, and you are ready to start modifying/adding files, staging, and committing.
1) The Workspace
The workspace is where all of your current project files live. You can add new ones, change existing ones…etc. Lets create a file:
echo 'Hello World' > README
You should see something like this:
This will list any and all files that have not been staged or committed.
When you have a file (or many) that are updated with, say, a new release of your project, you can stage those files by typing:
git add filename1 filename2 filename3...
Then you can type
git status again to see that those files have been moved to the staging area. This means they are ready to commit.
When you commit, you are saying that all the staged files are ready to be saved as a permanent record of your project at that point in time. The more often you commit, the more versions of your project you have saved, so you can always go back and see what your project looked like at a given point in time. You commit by typing:
git commit -m 'description of commit goes here'
If you forget the -m with the comment, it will take you into your default text editor (probably Vim), and ask you to type your comment to go along with this commit. If you get into vim, type (but without the ) to change to insert mode (so you can type), then press and type to write out and quit the editor. You have now made your commit! All staged files, and previously committed files, are saved in that commit, and you can return to the workspace and make more updates/changes.
So thats Git in a nutshell. Keep in mind that if your hard drive crashes, you will lose all of your projects including all of your commits. To eliminate this risk, and to allow for collaboration on projects, you’ll want to use Github, which I will discuss in my next post.