Skip to content

Latest commit

 

History

History
152 lines (91 loc) · 6.41 KB

File metadata and controls

152 lines (91 loc) · 6.41 KB

Setup | Shells | Markdown and IDEs | Git |Virtual Environments | Task Management | Advanced Shells

Git

image

Why Version Control?

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

📒 Online Exercise: Understanding Git's Object Model

↳ Click the following to start the exercise.

Practice: Creating a Repo from Scratch

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!

Stage, unstage, and discard changes

Changes flow from our working tree, to staging index, and into repository.

git-staging

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

Remotes

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...

git-remote

Remote operations

  • 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.

  1. Create a repo on GitHub (If you are a NCSU student, use GitHub Enterprise: https://github.ncsu.edu).

  2. 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

  3. Push your changes to GitHub. Verify you can see your updated README.md!

  4. 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.

  5. Run git pull and verify you now have the updated changes.

Git Branching Playground

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/

example

Git Configuration and Security

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: