Git Quicksheet by nvmoyar

Recent commit/s

nvmoyar — 2017-11-16 09:30:41 UTC

last commit:
$ git log -1 --> equivalent to git show HEAD
$ git log
----
$ git show HEAD~1 (previous to last commit)
$ git show HEAD~2
(HEAD-2 commits ago)

Last commit changes

nvmoyar — 2017-11-16 09:38:19 UTC

$ git show
$ git show 2343 (first hash chars)
The first part is the same as the log entry shown by git log. The second part shows the changes; as with git diff, lines that the change removed are prefixed with -, while lines that it added are prefixed with +.

What is going to be committed?

nvmoyar — 2017-11-16 09:50:50 UTC

In order to compare the file as it currently is to the changes in the staging area, you can use git diff -r HEAD filename. The -r flag means "compare to a particular revision", and HEAD is a shortcut meaning "the most recent commit". We will explore other uses of -r and HEAD in the next chapter.

Who changed that file

nvmoyar — 2017-11-16 10:57:49 UTC

$ git annotate file

Git Diff

nvmoyar — 2017-11-16 11:11:27 UTC

$ git diff 920252..4504188

Unwanted files

nvmoyar — 2017-11-16 11:21:49 UTC

$ git clean -n
will show you a list of files that are in the repository, but whose history Git is not currently tracking
$ git clean -f
will then delete those files.

Git Configuration

nvmoyar — 2017-11-16 11:28:56 UTC

$ git config --list (AND one of these flags)

--system: settings for every user on this computer.
--global: settings for every one of your projects.
--local: settings for one specific project.

git config --global setting.name myemail@email.com

Undo changes to unstaged files

nvmoyar — 2017-11-16 11:56:15 UTC

$ git checkout -- filename
(two scores - - )

Unstage a file already staged

nvmoyar — 2017-11-16 12:09:18 UTC

$ git checkout -- filename
Discard the changes in your repository.
will undo changes that have not yet been staged.
If you want to undo changes that have been staged, you can use

$ git reset HEAD filename
This does not restore the file to the state it was in before you started making changes. Instead, it resets the file to the state you last staged.
If you want to go all the way back to where you were before you started making changes, you must

$ git checkout -- filename

(You may be wondering why there are two commands for re-setting changes. The answer is that unstaging a file and undoing changes are both special cases of more powerful Git operations that you have not yet seen.)

Restore an old version

nvmoyar — 2017-11-16 12:12:53 UTC

$ git checkout 2242bd report.md

Undo all the changes made

nvmoyar — 2017-11-16 12:36:38 UTC

Git command to remove all files from the staging area
$ git reset HEAD .
Re-set those files to their previous state
$ git checkout -- .

Git Diagram

nvmoyar — 2017-11-16 12:53:34 UTC

nvmoyar — 2017-11-16 13:24:42 UTC

Git branches

nvmoyar — 2017-11-16 13:30:00 UTC

Git list branches
$ git branch
Git differences btw branches
$ git diff summary-statistics..master
Change branch name
$ git checkout branch-name
Create branch
git checkout -b deleting-report

Remove a file

nvmoyar — 2017-11-16 14:20:05 UTC

$ git rm report.txt

Git merge

nvmoyar — 2017-11-16 14:33:48 UTC

$ git merge summary-statistics master
Git without edit and message
$ git merge --no-edit -m "Merging altered report title" alter-report-title master

Git Clone and Working with remotes (Push/Pull)

nvmoyar — 2017-11-16 15:11:47 UTC

$ git clone file:///home/thunk/repo dental
A remote is like a browser bookmark with a name and a URL. If you are in a repository, you can list the names of its remotes using git remote.

How can I define remotes?

When you clone a repository, Git automatically creates a remote called origin that points to the original repository. You can add more remotes using:

*************** Add remote ********************

git remote add remote-name URL

git remote add remote-name URL

and remove existing ones using:

git remote rm remote-name

$ git remote add thunk file:///home/thunk/repo

You are in the master branch of the repository dental, which has a remote called origin. Pull all of the changes in the master branch of that remote repository into the master branch of your repository.

$ git pull origin master
$ git push origin master

**************** Change remote ******************

git remote -v
git remote set-url origin https://github.com/USERNAME/REPOSITORY.git
git push -u origin master

Good practices writing commits

nvmoyar — 2018-02-08 09:33:41 UTC

subject (mandatory) = type + title

Subjects should be no greater than 50 characters, should begin with a capital letter and do not end with a period. Use an imperative tone to describe what a commit does.

type (values):

feat: a new feature
fix: a bug fix
docs: changes to documentation
style: formatting, missing semi colons, etc; no code change
refactor: refactoring production code
test: adding tests, refactoring test; no production code change
chore: updating build tasks, package manager configs, etc; no production code change

\n (mandatory)

body(optional): Use the body to explain the what and why of a commit, not the how. 72 chars max.
\n (mandatory)
footer(optional): The footer is optional and is used to reference issue tracker IDs.

Example of git working workflow

nvmoyar — 2018-02-08 09:50:32 UTC

git branch -a // list my branches
- case1: the name of my new branch do not exist :
git checkout -b [my new branch name] // creates new brach
- case 2: the name of my new branch is already exist but i dont have that branch on my local :
git checkout -b [already existing branch] origin/[already existing branch] /

git status // check changes
git add . // if some and we want to stage them all (or we can do it individually etc.)
git commit -m "doc: Check the commit message to prevent error propagation"
git push -u [my new branch name] OR git push (if I'm already on the branch)
git merge --no-ff origin/[my new branch name/existing branch] // merges your branch

Git unrelated stories

nvmoyar — 2018-02-27 12:03:12 UTC

"git merge" used to allow merging two branches that have no common base by default, which led to a brand new history of an existing project created and then get pulled by an unsuspecting maintainer, which allowed an unnecessary parallel history merged into the existing project. The command has been taught not to allow this by default, with an escape hatch --allow-unrelated-histories option to be used in a rare event that merges histories of two projects that started their lives independently.

Git rebase

nvmoyar — 2018-02-27 15:47:58 UTC

Remove untracked files added to .ignore (.gitignore is is ignoring the untracked files)

nvmoyar — 2018-04-16 10:19:31 UTC

git rm -r --cached .
git add .
git commit -m "F untracked files"

Git objects

nvmoyar — 2018-04-25 08:11:29 UTC

Git stores four kinds of objects in the repo: blobs (files)

trees (directories)
commits (which form a directed acyclic graph through parent identifiers, with each commit carrying one tree object, one author, one committer, its set-of-parents, and an arbitrary log message)

annotated-tag objects (which have no strongly defined relationship, but every tag has exactly one target object, normally a commit).

Remove staged

nvmoyar — 2020-12-06 18:53:37 UTC

Remove staged without removing the actual files
git rm --cached -r .

https://stackoverflow.com/questions/19730565/how-to-remove-files-from-git-staging-area#:~:text=to%20unstage%20all%20the%20staged%20files.&text=git%20rm%20%2D%2Dcached%20%2Dr,you%20want%20to%20keep%20tracking.