An Introduction To The Command Line, Git & GitHub
"The command line is an interface that allows you to talk directly to your computer using words called commands."
Modifications are made through options, commands that come after the command. Options are preceded by a dash. i.e. `command -option`
Option `--help` will spell out the details of the command you precede it with.
Know that the directory is just another name for a folder.
| Command | Use | |----------------|-----------------------------------------| | `whatis` | a look up command i.e. `whatis cd` | | `cd` | change directory | | `cd ..` | go back one directory | | `cd - ` | go back to previous working directory | | `ls` | list (files in directory) | | Tab | completing arguments | | CTRL-P/CMMD-P | recalls the previous command (up arrow) | | CTRL-R/CMMD-R | search command history | | CTRL-W/CMMD-W | deletes the last word | | CTRL-U/CMMD-U | deletes the whole line | | CTRL-L/CMMD-L | clear screen |
The language. Not the British term for an idiot.
Distributed Version Control System - DVCS makes it possible to track the changes various authors make to a file or set of files & smoothes out the process of combining their files while preserving old versions. Makes for easier collaboration & effective combining of changes.
Just like with the Command Line, commands are formatted without spaces and can be followed by an option. However, all Git commands begin with the word git.
git add filename.html git commit -m "new file" git push origin newbranch
The platform. A web based repo hosting service.
Repository - a directory that is enabled to interact with Git & GitHub. Abbreviation: repo.
Within each repo there are three trees... 1. Working Directory - houses the files (what you see in your folder) 2. Index - the staging area 3. HEAD - the last commit
Commit - a snapshot of the file at a specific state. Staged - files ready to be committed. Unstaged - files that have been changed and not ready to commit Untracked - files that git isn't tracking, usually new. Deleted - a file you have removed from a folder but is waiting to be removed from the repo via git.
Branch - a separate work area. A version/copy of the repository that authors can change without affecting the master branch but can later merge with the master branch to make a big change all at once. Push - The final command to commit changes made in the working directory to the branch Pull - a command used to update your working directory with the latest changes to the branch.
Logging into your GitHub account in your Terminal
git config --global user.name "John Doe" git config --global user.email email@example.com
You will only have to do this once.
This is what we mean when we say repo. You're student loans have not been called in. We are not repossessing your macbook.
Creating a repo (Terminal):
Last login: Fri Feb 31 11:11:11 on ttys000 Laptop-MBP:~ JohnDoe$ cd Repositories/ Laptop-MBP:Repositories JohnDoe$ ls mysite projectA maptimeLA projectB GoTtheories hackathon Laptop-MBP:Repositories JohnDoe$ mkdir newrepo Laptop-MBP:Repositories patriciarealini$ ls mysite projectA maptimeLA projectB GoTtheories hackathon newrepo Laptop-MBP:Repositories JohnDoe$ cd newrepo Laptop-MBP:newrepo JohnDoe$ git init
Creating a repo(Terminal):
Go to github.com/new or click on the + in the upper right hand corner of github in the browser & select new repository.
Match the name of your GitHub repo with the name you gave the directory/repo on your computer
Creating a repo(Terminal):
Go back to the Terminal.
Laptop-MBP:newrepo JohnDoe$ git remote add origin https://ww w.github.com/JohnDoe/newrepo.git Laptop-MBP:newrepo JohnDoe$ git push -u origin master
Making changes to files in the repo.
Now that we have a repo to work in we can start adding files & working on them. Remember, the whole reason for working with GitHub is to have a record of changes you make to your file, so start committing right away!
To demonstrate we will start by creating a README file. Create the files & place it in the working directory for your repo.
Check your repo for unstaged/staged/untracked files by entering `git status` in the terminal. You should see `README.md` in red under "Changes not staged for commit".
To move the README into the staging area. Enter `git add README.md`.
Enter `git status`. This time, README should be in green under "Changes to be committed".
Enter `git commit -m "adding README file"`. the `-m` stands for message. Commits will be rejected without a message.
Enter `git status`. There should be no trace of your README file. README has been committed to your repo & now we need to push it to the branch. (We'll get to branches in a minute.)
The last step to finalize the update is pushing the changes to a repo & branch on GitHub. For this step we will enter `git push origin master`.
Making changes to the project as a whole.
Branches are places where you can make changes, without affecting the master branch. It's important to start working this way from the get-go because when you get on bigger & bigger projects, you will want to test your changes before you make them public. You can have as many branches as you want. Let's make our first branch!
Enter `git branch` to check the branches available to you at this time. Your terminal should output `* master` since you haven't yet made any other branches.
Enter `git branch testingbranch` to create a new branch called testingbranch.
Enter `git branch` to verify the creation of testing branch. This time your Terminal will output `* master testingbranch`.
Enter `git checkout testingbranch` to switch over to the testingbranch. Now all the commits you make need to be pushed to the branch you are in. From now until you switch, pushing will be finalized with the command `git push origin testingbranch`.
You can bypass step 2 by modifying step 3 to `git checkout -b testingbranch`. This does step 2 & 3 at the same time.
Once you've settled into a branch & will only be pushing to that one branch, you can command the push with `git push -u origin testingbranch` and shorten your push command to `git push` until you change branches. You will have to switch it in your push command by reverting back to the older command `git push origin branchname`.
Getting other people's changes.
Cloning is when you create a working directory of a repo on your computer. You are basically joining the project.
Pulling is when you update your working directory with all the most recent changes made to the repo. Pulling, like pushing, is related to branches.
To clone a repo from the Terminal. First `cd` to the directory where you want the clone to land. Then enter `git clone url.git`
To finalize your clone, simply push (just as we did when we created a repo), by entering `git push origin master`.
Regularly pulling is important. It keeps your working directory up to date with your repo. To pull a repo first checkout to the branch you want to pull from: `git checkout master`
Then enter `git pull origin master`.
To get all the changes on all the branches, enter `git pull --all`.
When changes don't match up.
Merging is when you want to join the work of one branch, back up with another (most commonly the master branch).
To merge you must be in the branch you wish to add the changes to i.e. the master branch. What is that command?
`git checkout master`!
Once you are in the branch you wish to add the changes to, you can enter `git fetch origin`.
Then `git checkout -b testingbranch`.
And lastly `git merge master`.
Conflicts will return an error in your terminal & ask you to go to the file & resolve the conflict.
Once you open the file, you will look for something like this...
Here are lines that are either unchanged from the common ancestor, or cleanly resolved because only one side changed. <<<<<<< yours:sample.txt Conflict resolution is hard; let's go shopping. ||||||| Conflict resolution is hard. ======= Git makes conflict resolution easy. >>>>>>> theirs:sample.txt And here is another line that is cleanly resolved or unmodified.
Making someone else's work, your own.
Forking is often confused with cloning. However, forking is a little more detached. A fork cannot be joined with the original repo, it is it's own repo. People fork so that they can learn from other people's repos as well as creating something new.