** i've found that often phase 1er's have a pretty jumbled idea of some of the basic git commands and why they're relevant to them as software engineers. i try to approach this lecture from a 'myles' perspective, meaning 'this is how to be a good developer'. teaching them the basic git workflow might be somewhat out of scope of their workflow for phase 1, but often ties together the loose ends of their understanding of git.
provide students with a more thorough understanding of git and github. main learning objectives are:
- understanding Git vs Github
- what happens when I clone
- typical "realworld" git workflow
- tools
github is a tech company (just down the street) that provides a service for developers to host their code repositories. they make their money off private repositories. the service they provide is to host your repositories and they also allow for many developers on a team to collaborate on a single code base.
git is a software program that allows for version control, which is basically a way of saving your progress at incremental points throughout development - kinda like a checkpoint in mario bros. at any point, a developer can look back at a 'checkpoint' to see what the code was doing, and even reset their project to that checkpoint if they've gone to a dark place.
cloning is a way to initiate a project on your local machine. it takes an exact copy of the code in the github repository and transfers it to your local machine. additionally, it begins tracking any changes you make to that code base (the equivalent of running git init). behind the scenes, it creates a hidden folder in the project directory called '.git'. this folder is really hard to get to, but it's there working some magic behind the scenes. all the contents of this folder are responsible to tracking all the changes you make to the software program, as well as maintaining the connection to the original repository (origin) and any other connection (heroku, for example). you only have to run git clone ONCE!
- git clone maintains a connection between the original repository and your local machine. any change created on the local machine is relevant to the original repository and the push/pull request process will go straight to that repo. submitting a pull request from a cloned repo requires that you are given 'contributer' access to that repo. clone is a git command that runs from the command line.
- forking creates a copy of the repo, but rather than transferring it to your local machine, it creates a new repo on your own github account. then, a developer would be able to clone the newly created repo and make changes on it locally as per usual. if the developer intends to add their modifications to the ORIGINAL repo, they must make an outside pull request to that repo from their own github repo. this is the process for contributing to open source projects. forking is not a git command, but rather a concept or process that you do from within github.
important aspects to hit here:
- git init
creates a hidden folder in the directory called '.git/'. this folder contains all the magic that git needs to start tracking your files and managing the changes that you make to your code. - git remote add
this command will allow you to add a connection from the directory on your local computer to the given location. this is also managed by the '.git/' folder magic. if setting the connection to the main github repo, you would run
$ git remote add origin http://github.com/your_repo_url
- branching
never working on the master branch. the branch is what you will eventually push up to github, so make sure it's not master. - staging
taking a chunk of code from the bucket of changed code, and adding it to the staging area. the command for this is 'git add'. this is in preparation of a 'commit', and can be performed repeatedly until the staging area contains all the desired chunks of code for the commit - committing
a way of packaging all the code that is in the staged area and saving it as an organized chunk of code that is ready to be pushed. this acts as a checkpoint of sorts for the project. a developer would be able to 'reset' the project to this exact state in development. commit's also allow for an opportunity to tell the story of the software. any developer should be able to look at the commit history of a project and be able to see the story of the software - what is this software doing, how did that change throughout time, what were the developers thinking about as they wrote this software, etc... the command for this is 'git commit'. committing is in preparation of 'pushing', and can be done repeatedly until you have a working piece of software that deserves pushing. - pushing
the process of taking all of the commits that have been made and sending them from your local machine to somewhere else, often times to the 'origin', or the original github repo. in the real world, you are hopefully not pushing to master, but rather pushing your branch up in preparation of a pull request. the command for this is 'git push origin BRANCH_NAME' - pull request
sometimes the verbage of a pull request is a little tricky, so let's be clear. a developer submits a pull request in an attempt to add a chunk of code to the that they wrote to the main project. to whoever is doing the code review (maybe a lead developer), they're requesting that person pull (or merge) the code into the main branch. hopefully there is a code review done by the lead developer at which point they either say yes, this code deserves to be in our main branch, or no, this code needs improvement. - pull master
after a pull request is accepted and merged into the master branch on github, each developer working on that project needs to pull that new and improved version of the code down to their local machine. this way, developers aren't working on chunks of code that have already been written/deleted/modified on the master branch. this will help avoid messy merge conflicts and wasted time spent doubling work. in order to pull master, checkout to the master branch locally ('git co master'), and then the command is 'git pull origin master'.
- git add -p
most people are aware of the ability to add code to the staging area using 'git add .' or maybe 'git add -A'. the problem with both of these tools is they both dump the entire bucket of changed chunks of code out onto the staging area. in order to gain more insight and control with the staging process, i recommend using 'git add -p'. 'git add -p' will take you step by step through each chunk of changed code in the bucket, allowing you to choose for each chunk whether or not it should be staged. assuming we are motivated to make clear, concise, and thoughtful commits, then we should start that process with thoughtful staging. - git commit -v
again, most people are aware of 'git commit -m' which will allow you to write a short commit message on the command line. but i recommend using 'git commit -v' which will open the commit in your system's default text editor (may require some setup), and allow you to leave a more verbose commit message from within your editor. this will also allow you to look at the code you are committing, which can be beneficial as a double check to make sure it's the code you were expecting.
@waneka this looks awesome dude. I would've loved this as a phase 1'er.
I was thinking a optional resources list would be helpful for students who want to deep dive post lecture:
Optional Resources:
Code School's - Learn Git
Learn Git Branching - Visually!