How to Git

A quick(ish?) guide on how to use Git. Shamelessly a ripoff summary from this guide. Was written to help onboard new Daily Bruin Online contributors but hopefully anyone new or needing a refresher on Git can find this helpful.

What is Git?

Git is a DVCS (Distributed Version Control System) that stores a progression of snapshots of a file system.

Each file in Git will have 1 of 3 states:

• Committed: File is securely stored in a local database
• Modified: File has been changed but not committed to the database
• Staged: File is "flagged" as ready to be committed in the next snapshot

Setting up Git

To set up your identity, which will be used for every Git commit, run these commands:

2
1
git config --global user.name "Richard Yang"
2
git config --global user.email "richard@yang.com"

To set up the default text editor Git will use, run one of these commands with your favorite editor:

4
1
git config --global core.editor emacs
2
git config --global core.editor "code --wait"
3
git config --global core.editor "atom --wait"
4
git config --global core.editor "subl -n -w"

For VSCode, make sure that which code actually returns a path. If not, open VSCode, open the Command Palette (Shift + Command + P), and search for "**Shell Command: Install 'Code' command in path****".

You can use git config --list to check your settings, and git config --edit to test that your default text editor is linked correctly.

Structure of Local Repository

The local Git repository has three components:

• Working directory: the actual files that are in the directory
• Index: The area used for staging, a rough draft for your next snapshot
• Head: The most recent snapshot (of the branch you are on)

All files in a Git repo are either Tracked or Untracked. Tracked files can be:

• modified (I want to change this file)
• unmodified (I want to revert this file back to the most recent snapshot)
• staged (I think my changes to this file are ready to be committed)

Untracked files, in the eyes of Git, do not exist until you tell Git to start tracking them.

To check the state of your files, use git status. To start tracking files, use git add [FILE-NAME]. To stop tracking files, use git rm --cached [FILE-NAME]. To add all files in a directory recursively, use *. To add all files in the first layer of your directory, use .. To commit your files in stage, run git commit -m "changed x, y, and z".

Workflow

Getting a Git Repository

Import existing local project into Git:

1. cd into the target directory
2. git init
3. git add [ALL FILES YOU WANT TO TRACK]
4. git commit -m "the first commit of this git repo :^)"

Cloning existing Git project into your local computer:

1. git clone [REPO'S URL HERE]

When you clone a Git repo, Git will automatically name the server "origin" and your local branch "master".

Updating a Git Repository

If it's been a while since you've last touched the code to a repo, you want to make sure you have the most updated version before you start making changes. There are two ways of doing so, git fetch and git pull.

• git fetch [REMOTE-NAME] updates Head. **This does not change your working copy.****
• git pull [REMOTE-NAME] does a git fetch then merges Head and your working copy automagically (which should work most of the time).

Making Changes

In DB we enforce the use of branching, so we are assuming that when you want to make a change, you would want to create a branch. Branching is a good practice as it allows for multiple people to work on their own branches without affecting the main repository.

To create a new branch use git branch [BRANCH-NAME]. To delete a branch use git branch -d [BRANCH-NAME]. In DB, the naming convention of branches is [NAME]/[FEATURE]. To switch to another branch use git checkout [BRANCH_NAME]. It is very common to want to create and switch to the newly created branch. To do so use git checkout -b [BRANCH-NAME]. If you want to see all available branches, use git branch.

Once you're happy with your changes you've made to your branch, run git add <files> <added> <or> <modified> to move them from untracked to tracked and then git commmit -m "fixing x" to move them from tracked to staged.

Pushing your changes

Now that your changes are committed to your local repo, you need to push your code to the remote repo so other people can access your code! To do so we need to use: git push -u [REMOTE-NAME][BRANCH-NAME].

Most of the time, [REMOTE_NAME] will be "origin". The -u option allows you to just do git push in the future if you push more code to the repo.

Making a PR

Once you have pushed your code to github, head to the repo online and make a PR. Once that's finished, wait for your code to be reviewed (you may have to add more changes to the PR). Because this process can take a while, there may have been changes to master that are not reflected in your branch! To update your branch with new code from master, you can run

2
1
git checkout [BRANCH-NAME]
2
git merge master

which is the same as running git merge master [BRANCH-NAME]. Git will try its best to weave the updated master branch and your branch, but sometimes there are changes that require a human to step in and sort out. If this happens you will need to commit the merge changes and push your code again.

If you ever get confused, remember you have git status!

Misc

Resetting

Sometimes stuff happens and you just need a hard reset. To do so run these commands:

3
1
git checkout master
2
git fetch origin
3
git reset --hard origin/master

Stashing

Somtimes you are not ready to commit your changes, but still want to switch branches. In this case you can use git stash to tell git to save your current work in a snapshot elsewhere and turn your working directory into a clean state. the stashed snapshots are placed on a stack, which you can look at using git stash list.

If you want to get back your work back, you can run git stash apply [STASH-NAME] to get back a specific snapshot, or omit [STASH-NAME] to get back your most recent stashed work.

To remove snapshots from your stash, use git stash drop [STASH-NAME]. The usage (and omission) of [STASH-NAME] works the same as git stash apply. I would recommend playing around with this in a dummy git repo to make sure you get a feel before using it on actual code you want to push.

Panic

This deserves more than a section, but if you ever think you've really messed up, be sure to search up git reflog. You may be able to recover some work you thought you lost forever.

Conclusion

Hopefully you have learned something new, let me know if anything is wrong! There is more about Git that I left out (merging vs rebasing, squash merging, tagging, logs) because I felt like they were not super necessary for having working knowledge of Git (also I didn't really want to write up about it :)). This is where I say to use the internet to look up things that I've missed! As a starting point, I found that Atlassian has very good and easy to follow write-ups on the topics I've covered and more.

[home]