GitHub Office / Ben Scholzen
Although I did find the session useful, it unfortunately moved a bit too fast and with demos that were hard to make out on the big screen due to the high resolution of the image. I tried to keep up while trying things out, but quickly found myself lost. (Funnily enough, it was when John started demoing Git from the command line that I was really able to get a handle on things.) I'll share some of trickier bits I was able to figure out during the session along with my own research below.
I admittedly still get confused by Git since I haven't used it for any of my own projects. The key thing to sort out is the workflow, which is different from version control systems like CVS and SVN:
- The first step in making changes to an existing project is to clone it. This fetches a repository that you don't yet have locally.
- Next, you can checkout a new branch, giving it a name and activating it (or, if the branch already exists, just switch to it). There is some useful discussion about the difference between clone and checkout here.
- After making some changes to files or adding new ones, you can use git status to review those changes.
- If there's a new file that you want to be tracked by Git, you need to add it.
- When ready, you can commit your current set of changes to the repository, creating a snapshot of sorts.
- Finally, when you are ready to send your local snapshot to your Git repository, you push.
If you aren't familiar with branching and merging, this article might be useful. You might also like Code School's interactive lessons on GitHub to get a feel for the system overall.
One last thing: if you are a student, you must check out this recently announced student pack, which includes access to a free micro account on GitHub (this lets you have private repositories). Awesome!!