DEV Community

loading...
Cover image for GitSheet - my git cheatsheet

GitSheet - my git cheatsheet

myrtle profile image Mrtl Updated on ・7 min read

GitSheet

a cheatsheet that's lived in my notepad for too long


Add existing local project to GitHub

$ git init
$ git add .
$ git status //sanity check
$ git commit -m <message>
$ git remote add origin <github-repo-url>
$ git remote -v //sanity check
$ git push -u origin <master> //or other branch

Add a file afterwards
$ git add <path/to/file> or $ git add . //if you got a few to add, careful not to commit any unwanted files here
$ git restore --staged <file> //to unstage those you don't want to commit
$ git status //sanity check
$ git commit -m <message>
$ git push origin branch-name

If you accidentally initialise a git repo in a folder that shouldn't be under version control
Revert the change by removing the hidden .git folder
$ rm -rf .git

Updating file
Use $ git add <file> to update what will be committed
If you don't want these changes and just want to go back to the version of this file at the time of the last commit
Use $ git checkout --<file> to discard changes in working directory

Sanity checks: run $ git status before you commit, to confirm that the repo is in the state you expect it to be.


On remotes

Create new branch with switch
$ git switch -c branch name
(is the same as $ git checkout -b <branchname>)

Push a new branch up to remote
$ git push -u origin <branchname>

Set a new remote
$ git remote add origin https://github.com/user/repo.git

Verify new remote
$ git remote -v


Navigating The Log

To view all of the commits we've made, we run:
$ git log
$ git log --oneline //keep things simpler
(TLDR use ↓ or enter/return key to move further down, $ q to quit)

If you're not used to a pager on the command line, navigating in Less can be a bit odd.

  • to scroll down, press
    • j or ↓ to move down one line at a time
    • d to move by half the page screen
    • f to move by a whole page screen
  • to scroll up, press
    • k or ↑ to move up one line at a time
    • u to move by half the page screen
    • b to move by a whole page screen
  • press q to quit out of the log (returns to the regular command prompt)

More Sanity checks

Stats
$ git log --stat

  • displays the file(s) that have been modified
  • displays the number of lines that have been added/removed
  • displays a summary line with the total number of modified files and lines that have been added/removed

$ git log -p (or patch)
Shows the diff between files changed
This command adds the following to the default output:

  • displays the files that have been modified
  • displays the location of the lines that have been added/removed
  • displays the actual changes that have been made

You can "log" information with:
$ git log
$ git log --oneline
$ git log --stat
$ git log -p
You can supply the SHA of a commit as the final argument
ie. $ git log -p fdf5493
git log -p command will start at that commit & show all commits made prior to the supplied SHA
The git show command will show only one commit. 

To unstage: $ git rm —cashed <file>

$ git diff displays:

  • the files that have been modified
  • the location of the lines that have been added/removed
  • the actual changes that have been made

On gitignore

Add the file inside the .gitignore file: ie. info.md

In the .gitignore file, you can use the following:

  • blank lines can be used for spacing
  • # - marks line as a comment
  • * - matches 0 or more characters
  • ? - matches 1 character
  • [abc] - matches a, b, or c
  • * - matches nested directories - a/*/z matches
    • a/z
    • a/b/z
    • a/b/c/z So if all of the 50 images are JPEG images in the "samples" folder, we could add samples/*.jpg to .gitignore to have Git ignore all images.

On git tag

Git tag
$ git tag -a beta
This command will:

  • add a tag to the most recent commit
  • add a tag to a specific commit if a SHA is passed $ git tag -a v1.0 git log --decorate A Git tag can be deleted with the -d flag (for delete!) and the name of the tag: $ git tag -d v1.0  But what if you wanted to tag a commit that occurred farther back in the repo's history? All you have to do is provide the SHA of the commit you want to tag! $ git tag -a v1.0 a87984

On branches

git branch can be used to:

  • list all branch names in the repository
  • create new branches
  • delete branches if we type out just $ git branch it will list out the branches in a repository if you want a branch called "something", you'd run this command: $ git branch something to switch between branches: $ git checkout something this command will:
  • remove all files and directories from the Working Directory that Git is tracking (files that Git tracks are stored in the repository, so nothing is lost)
  • go into the repository and pull out all of the files and directories of the commit that the branch points to

DELETE a branch
$ git branch -d something

to list all branches:
$ git branch

to create a new "footer-fix" branch:
$ git branch footer-fix

to delete the "footer-fix" branch:
$ git branch -d footer-fix

See All Branches At Once
$ git log --oneline --decorate --graph --all


On merging

$ git merge <name-of-branch-to-merge-in>

  • look at the branches that it's going to merge
  • look back along the branch's history to find a single commit that both branches have in their commit history
  • combine the lines of code that were changed on the separate branches together
  • makes a commit to record the merge

There are two types of merges:

  • fast-forward merge – the branch being merged in must be ahead of the checked out branch. The checked out branch's pointer will just be moved forward to point to the same commit as the other branch.
  • regular merge
    • two divergent branches are combined
    • a merge commit is created

On merge fails / merge conflics:

A merge conflict will happen when the exact same line(s) are changed in separate branches
The git status output tells us to that the merge conflict is inside index.html. So check out that file in your code editor!
Merge Conflict Indicators Explanation
The editor has the following merge conflict indicators:

  • <<<<<<< HEAD everything below this line (until the next indicator) shows you what's on the current branch
  • ||||||| merged common ancestors everything below this line (until the next indicator) shows you what the original lines were
  • ======= is the end of the original lines, everything that follows (until the next indicator) is what's on the branch that's being merged in
  • >>>>>>> heading-update is the ending indicator of what's on the branch that's being merged in (in this case, the heading-update branch)
  1. choose which line(s) to keep
  2. remove all lines with indicators  To resolve the conflict in a file:
  3. locate and remove all lines with merge conflict indicators
  4. determine what to keep
  5. save the file(s)
  6. stage the file(s)
  7. make a commit

commit amend

Now with the --amend flag, you can alter the most-recent commit.
$ git commit --amend -m 'your text'

If your Working Directory is clean (meaning there aren't any uncommitted changes in the repository) running $ 
git commit --amend will let you provide a new commit message.

Add Forgotten Files To Commit

  • edit the file(s)
  • save the file(s)
  • stage the file(s)
  • and run git commit --amend

for the 'OH NO' moments

⚠️ Resetting Is Dangerous ⚠️
Resetting erases commits!

Ancestry References

that we can use to tell Git about relative references

  • ^ – indicates the parent commit
  • ~ – indicates the first parent commit Here's how we can refer to previous commits:
  • the parent commit – the following indicate the parent commit of the current commit
    • HEAD^
    • HEAD~
    • HEAD~1
  • the grandparent commit – the following indicate the grandparent commit of the current commit
    • HEAD^^
    • HEAD~2
  • the great-grandparent commit – the following indicate the great-grandparent commit of the current commit
    • HEAD^^^
    • HEAD~3

commit revert

When you tell Git to revert a specific commit, Git takes the changes that were made in commit and does the exact opposite of them
Git will make a new commit
$ git revert <SHA-of-commit-to-revert>
This command:

  • will undo the changes that were made by the provided commit
  • creates a new commit to record the change

$ git reset <reference-to-commit>
OR use the ancestry refs

For example if you made a merge on the wrong branch, use this command to undo the merge:
$ git reset --hard HEAD^
Make sure to include the ^ character, the "Relative Commit Reference" indicates "the parent commit".

It can be used to:

  • move the HEAD and current branch pointer to the referenced commit
  • erase commits
  • move committed changes to the staging index
  • unstage committed changes The way that Git determines if it erases, stages previously committed changes, or unstages previously committed changes is by the flag that's used. The flags are:
  • --mixed (the default, places changes back in the working dir)
  • --soft (will put them into the staging are)
  • --hard (will throw out all changes) *** Good idea: a backup branch, in case u mess up $ git branch backup

Reset Recap
To recap, the git reset command is used erase commits:
$ git reset
It can be used to:

  • move the HEAD and current branch pointer to the referenced commit
  • erase commits with the --hard flag
  • moves committed changes to the staging index with the --soft flag
  • unstages committed changes --mixed flag Typically, ancestry references are used to indicate previous commits. The ancestry references are:
  • ^ – indicates the parent commit
  • ~ – indicates the first parent commit


This cheatsheet has lived in my notepad for some time.
Of course all this info is out there on the wild web, certainly better written & explained. And there's a lot more to git and life-saving commands.
I'd love to know them & list them all but I prefer to know what I need to know at every moment, so this is where I'm at right now. I like my quick ref cheatsheets & so I am sharing it.
Regrettably I do not have refs of where all these snippets came from. Some are c/p, some are mine, many are from the official Atlassian guides.

Read up, then make your own cheatsheet :)




next:

I need to write a rebasing & squashing cheatsheet

Discussion

pic
Editor guide
Collapse
goodevilgenius profile image
Dan Jones

I would personally recommend not using git add . aside from the initial commit.

It's too easy to accidentally commit files you didn't mean to (temp files you were taking notes in, or even worse, files you were putting credentials in). Hopefully, you catch it when you do git status before you commit, but not adding in the first place is even better.

I prefer doing

git status # Check what's been changed
git add path/to/file some/full/dir/
git status # Check once more
git commit -m '😃 Some stuff'
Enter fullscreen mode Exit fullscreen mode
Collapse
myrtle profile image
Mrtl Author

You are right, add-all can be dangerous. Personally I trust my sanity checks so I use it a lot, for speed, and then I may remove the occasional unwanted file, if any.
I will update for clarity. cheers

Collapse
jonrandy profile image
Jon Randy

I use Gitkraken - way easier, and very intuitive

Collapse
mx profile image
Maxime Moreau

I use both GUI and CLI and the two are excellent :) CLI is not that hard, it depends on what you like. Enjoy!

Collapse
myrtle profile image
Mrtl Author

oooh a gui! I'll give that a try! cheers

Collapse
isarisariver profile image
Marian Beck

Copy&pasted to my own cheatsheet 😉

Collapse
tracycss profile image
Jane Tracy 👩🏽‍💻

This is a great cheat sheet. ✨💯

Collapse
hanifyogatama profile image