Setup | Shells | Markdown and IDEs | Git |Virtual Environments | Task Management | Advanced Shells
You're working on a team project and need to make edits to reports and code. You waiting for your team member to make a change and then email you back another a copy. There has to be a better way...
"Version control is the lab notebook of the digital world: it’s what professionals use to keep track of what they’ve done and to collaborate with other people. Every large software development project relies on it, and most programmers use it for their small jobs as well. And it isn’t just for software: books, papers, small data sets, and anything that changes over time or needs to be shared can and should be stored in a version control system." -- Version Control with Git
↳ Click the following to start the exercise.
Let's create a new local git repository.
We are going to create a new git repository, but maybe not the way you've done it before.
This will create a new .git directory to store commits and other objects.
mkdir Basics
cd Basics
git init
We can quickly inspect the contents of the git's directory and object store.
ls -l .git
echo "objects:"
ls -l .git/objects
Before adding a file to the repository, it must first be staged.
git add README.md
We will commit our staged changes into the repository.
git commit -m "initial commit"
Nice work!
Changes flow from our working tree, to staging index, and into repository.
Exercise: Use the following sets of steps and execute them in any order you wish. Observe what happens to the working tree and index, by running the git status step.
Update the README.md and stage our change.
echo " Update: $(date)" >> README.md
cat README.md
git add README.md
View the current state of our working tree and index.
git status
Unstage file (remove from index), but keep changes in working tree.
git restore --staged README.md
Discard changes in worktree (we will lose our work!). This will restore changes to both the index and the working tree based on the latest version in the repo.
git restore --source=HEAD --staged --worktree README.md
While having a local git repository is cool, we should connect it to another remote repository. In other words, we have no place to git push to...
- Get new data:
git fetch <remote> [branch] - Upload your data:
git push <remote> <branch> - Get new data and merge into working tree:
git pull <remote> <refspec>
Hot Take: Avoid git pull on large repositories! You may want to handle merges yourself into your target branch instead of having git mess with your working tree.
-
Create a repo on GitHub (If you are a NCSU student, use GitHub Enterprise: https://github.ncsu.edu).
-
Follow the instructions on GitHub to add a remote url to an existing git repository. Basically, you need to run something like:
git remote add origin https://github.com/<user>/<repo>.git -
Push your changes to GitHub. Verify you can see your updated README.md!
-
On GitHub, edit the README.md, to say "Hello GitHub!". Commit the changes on GitHub. Now you have changes in your remote (origin), that are missing on your local copy.
-
Run
git pulland verify you now have the updated changes.
Manipulating the commit graph can get quite complicated! This interactive visualization is very useful for getting a deeper understanding of how operations such as branches, merges, cherry-picking, and more work!
We will solve the "Introduction Sequence" levels in:
http://pcottle.github.io/learnGitBranching/
If you want to make sure your commits are properly linked to your GitHub account, make sure you have configured your computer to have your name and email filled out.
$ git config --global user.name "FirstName LastName"
$ git config --global user.email email@example.com
You might also consider an authenication strategy. If you're being asked to login everytime your pull/push to your remote repository, you might want to enable caching of your credentials. For example, you could use:
git config --global credential.helper store
However, this may store your credentials in plain text on your computer. There are other platform-specific credential.helpers that you can use to more securely store your credentials. It is also possible to generate personal access tokens that you can use authenicate instead of a passcode.
An alternative approach is to use sshkeys. In this case, you have a public/private keypair, with the public key stored on GitHub. You then use a different url pattern for your commands such as git clone. Instead of the https:// prefix, you instead use git@github.com:user/repo.git.
If you are interested in exploring this option: See these guides on GitHub:



