these are just notes for study https://git-scm.com/book/en/v2
git configs location
1. [path]/etc/gitconfig =:> applied to every user
=:> personal to u i.e $USER, --global edits this.
3. .git/config :=> localt to current repo u r working. --local edits this.
priotity of config is 3>2>1 as ususal in linux config
git config --list --show-origin
$ git config --global user.name "John Doe" $ git config --global user.email [email protected]
git config --global core.editor vim
Your default branch name
git init makes default branch master . to set main as default branch
git config --global init.defaultBranch main
Checking Your Settings
$ git config --list
$git config <key>
Getting a Git Repository
Initializing a Repository in an Existing Directory
cd to desired dir and run ::
This creates a new subdirectory named
.git that contains all of your necessary repository files — a Git repository skeleton use git add to track fiels(i.e do version controlling) and do commit message.
$ git add *.py $ git add README.md $ git commit -m 'Initial project version'
Cloning an Existing Repository
$ git clone
clones to $PWD/dellconfig
$ git clone
clones to $PWD/testclone
Recording Changes to the Repository
states of file in git :: Tracked(git knows about), Untracked (git is ignorant about)
1. Untracked :: new files or files that exists in system i.e all normal files
2. tracked ::
files added by git add filename. file will also be staged.
they can be unmodified, modified, or staged state.
unmodified = after commiting staged files or fresh pull from repo files are unmodified
modified = tracked file gets edited
staged = ready to commit files. git add filename will set file as staged.git
$git status -s
#short status ??= untracked A=staged M=modified
this give status of files
The rules for the patterns you can put in the
.gitignore file are as follows:
Blank lines or lines starting with
Standard glob patterns work, and will be applied recursively throughout the entire working tree.
You can start patterns with a forward slash (
/) to avoid recursivity.
You can end patterns with a forward slash (
/) to specify a directory.
You can negate a pattern by starting it with an exclamation point (
Glob patterns are like simplified regular expressions that shells use.
An asterisk (
*) matches zero or more characters;
[abc] matches any character inside the brackets (in this case a, b, or c); a question mark (
?) matches a single character; and brackets enclosing characters separated by a hyphen (
[0-9]) matches any character between them (in this case 0 through 9).
You can also use two asterisks to match nested directories;
a/**/z would match
a/b/c/z, and so on.
#ignore any files ending in “.o” or “.a”
#ignore all files whose names end with a tilde (
Viewing Your Staged and Unstaged Changes
#to view excat changes that are unstaged
#compares your staged changes to your last commit
$git diff --staged
#to see what you’ve staged so far (
git diff --cached
view in external tool
#list available difftool
$git difftool --tool-help
Committing Your Changes
#will launch $EDITOR i.e your fav editor or that set in
git config --global core.editor someeditor
#commit with diff changes
git commit -m"some commit message"
Every time you perform a commit, you’re recording a snapshot of your project that you can
revert to or compare to later. all staged state files are commited other are left as is.
after commit you can see in git status
Your branch is ahead of 'origin/master' by 1 commit.
Skipping the Staging Area
aoption to the
git commitcommand makes Git automatically stage every file that is already
tracked before doing the commit, letting you skip the
$ git commit -a -m 'Add new benchmarks'
git rmcommand tracked files (more accurately, remove it from your staging area) and then
commit and also removes the file from your working directory so you don’t see it as an untracked
file the next time around.
remove from staging
$ git rm --cached README
u can use glob patterns
$ git rm log/\*.log
$ git rm \*~
$ git mv file_from file_to
However, this is equivalent to running something like this:
$ mv README.md README $ git rm README.md $ git add README
Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that
way or with the
mvcommand.The only real difference is that
git mvis one command instead of
Viewing the Commit History
$ git log
shows all commit in reverse chronological order i.e recent first
$ git log -p -2
shows last 2 commits with diff
$ git log --stat
git log --pretty=oneline
git log --pretty=format:"%h - %an, %ar : %s"
git log --since=2.weeks
git log -S function_name
git log -- path/to/file
git log --pretty="%h - %s" --author='Junio C Hamano' --since="2008-10-01" --before="2008-11-01" --no-merges -- t/
|Specifier||Description of Output|
Abbreviated commit hash
Abbreviated tree hash
Abbreviated parent hashes
Author date (format respects the --date=option)
Author date, relative
Committer date, relative
git commit --amend
If you want to redo commit, make the additional changes you forgot, stage them, and commit
again using the
$ git commit -m 'Initial commit' $ git add forgotten_file $ git commit --amend
You end up with a single commit — the second commit replaces the results of the first.
Unstaging a Staged File
git statuscommand reminds you: after staging file using git add xx
(use "git reset HEAD <file>..." to unstage)
$ git reset HEAD CONTRIBUTING.md
Unmodifying a Modified File
(use "git checkout -- <file>..." to discard changes in working directory)
$ git checkout -- CONTRIBUTING.md
Any local changes you made to that file are gone — Git just replaced that file with the last
staged or committed version.
Undoing things with git restore
git restore.It’s basically an alternative to
git resetfor git >
Unstaging a Staged File with git restore
(use "git restore --staged <file>..." to unstage)
$ git restore --staged CONTRIBUTING.md
Unmodifying a Modified File with git restore
(use "git restore <file>..." to discard changes in working directory)
$ git restore CONTRIBUTING.md
Working with Remotes
Showing Your Remotes
gir remote -v
full repo with url and shortname
If you have more than one remote, the command lists them all.
Adding Remote Repositories
git clonecommand implicitly adds the
originremote for you
git remote add <shortname> <url>:
$ git remote add pb https://github.com/paulboone/ticgit
you can run
git fetch <shortname>
git fetch pb
Fetching and Pulling from Your Remotes
$ git fetch <remote>
git fetchcommand only downloads the data to your local repository — it doesn’t
automatically merge it with any of your work or modify what you’re currently working on.
You have to merge it manually into your work when you’re ready. you can use the
command to automatically fetch and then merge that remote branch into your current branch
Pushing to Your Remotes
git push <remote> <branch>
$ git push origin master
You’ll have to fetch first and incorporate it into yours before you’ll be allowed to push
Inspecting a Remote
git remote show <remote>
$ git remote show origin
Renaming and Removing Remotes
$ git remote rename pb paul
this changes all your remote-tracking branch names, too.What used to be referenced at
pb/masteris now at
to remove remote
git remote remove or
git remote rm:
$ git remote remove paul
Once you delete the reference to a remote this way, all remote-tracking branches and
configuration settings associated with that remote are also deleted.
used to mark releases
Listing Your Tags
$ git tag
$ git tag -l "v1.8.5*"
Git supports two types of tags: lightweight and annotated.
A lightweight tag is very much like a branch that doesn’t change — it’s just a pointer to a specific commit.
Annotated tags, however, are stored as full objects in the Git database. They’re checksummed; contain the tagger name, email, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG).
git tag -a v1.4 -m "my version 1.4"
-mspecifies a tagging message, opens $EDI
$ git tag v1.4-lwTOR if unspecified .
You can see the tag data along with the commit that was tagged by using the
git show command:
$ git show v1.4
To create a lightweight tag, don’t supply any of the
-moptions, just provide a tag name:
$ git tag v1.4-lw
$ git show v1.4-lw
Suppose your commit history looks like this:
$ git log --pretty=oneline
9fceb02d0ae598e95dc970b74767f19372d61af8 Update rakefile
To tag that commit, you specify the commit checksum (or part of it) at the end of the command:
$ git tag -a v1.2 9fceb02
it push origin <tagname>
$ git push origin v1.5
$ git push origin --tags
pushes all tags
when someone else clones or pulls from your repository, they will get all your tags as well.
git push <remote> --follow-tagsonly annotated tags will be pushed to the remote.
$ git tag -d v1.4-lw
The first variation is
git push <remote> :refs/tags/<tagname>:
$ git push origin :refs/tags/v1.4-lw
$ git push origin --delete <tagname>
Checking out Tags
$ git checkout v2.0.0
this puts your repository in “detached HEAD” state, which has some ill side effects:
In “detached HEAD” state, if you make changes and then create a commit, the tag will stay the same, but your new commit won’t belong to any branch and will be unreachable, except by the exact commit hash. Thus, if you need to make changes — say you’re fixing a bug on an older version, for instance — you will generally want to create a branch:
$ git checkout -b version2 v2.0.0 Switched to a new branch 'version2'
$ git config --global alias.co checkout $ git config --global alias.br branch $ git config --global alias.ci commit $ git config --global alias.st status
for example, instead of typing
git commit, you just need to type
git config --global alias.unstage 'reset HEAD --'
$ git unstage fileA
$ git config --global alias.last 'log -1 HEAD'
$ git last
external command with !
$ git config --global alias.visual '!gitk'
Git stores data as a series snapshots when you create the commit by running git commit, Git checksums each subdirectory (in this case, just the root project directory) and stores them as a tree object in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.
our Git repository now contains five objects: three blobs (each representing the contents of one of the three files), one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata.
master. As you start making commits, you’re given a
masterbranch that points to the last commit you made. Every time you commit, the
masterbranch pointer moves forward automatically.
Creating a New Branch
git branch testing
How does Git know what branch you’re currently on?
It keeps a special pointer called
Note that this is a lot different than the concept of
HEAD in other VCSs you may be used to, such as Subversion or CVS.
In Git, this is a pointer to the local branch you’re currently on.
In this case, you’re still on
git branch command only created a new branch — it didn’t switch to that branch.
$ git log --oneline --decorate
$ git checkout testing
HEAD to point to the
after you commit to testing branch only it moves forward
git log --oneline --decorate --graph --all
to show code changes in branches
Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).
It’s typical to create a new branch and want to switch to that new
branch at the same time — this can be done in one operation with
git checkout -b <newbranchname>.
for git >=2.23
Switch to an existing branch:
git switch testing-branch.
Create a new branch and switch to it:
git switch -c new-branch. The
-cflag stands for create, you can also use the full flag:
Return to your previously checked out branch:
git switch -.
Basic Branching and Merging
$ git checkout -b iss53
$ vim index.html
$ git commit -a -m 'Create new footer [issue 53]'
$ git checkout master
$ git checkout -b hotfix
$ vim index.html $ git commit -a -m 'Fix broken email address'
$ git checkout master
$ git merge hotfix
$ git branch -d hotfix
delete hotfix branch after it is no need
$ git checkout iss53
$ vim index.html
$ git commit -a -m 'Finish the new footer [issue 53]'
$ git checkout master
$ git merge iss53
This looks a bit different than the
hotfixmerge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two.
git branch -d iss53
Basic Merge Conflicts
If your fix for issue #53 modified the same part of a file as the
you’ll get a merge conflict that looks something like this:
git merge iss53
Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:
<<<<<<< HEAD:index.html <div id="footer">contact : [email protected]</div> ======= <div id="footer"> please contact us at [email protected] </div> >>>>>>> iss53:index.html
In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:
<div id="footer"> please contact us at [email protected] </div>
to mark as resolved and git commit
for graphical resolution
git branch -v
same with last commit
git branch --merged
see which branch are merged in curret branch
$ git branch --no-merged
This shows your other branch. Because it contains work that isn’t merged in yet, trying to delete it with
git branch -dwill fail:
Changing a branch name
$ git branch --move bad-branch-name corrected-branch-name
$ git push --set-upstream origin corrected-branch-name
$ git branch --all
$ git push origin --delete bad-branch-name
Changing the master branch name
$ git branch --move master main
$ git push --set-upstream origin main
mainbranch is present on the remote. However, the old
masterbranch is still present on the remote. Other collaborators will continue to use the
masterbranch as the base of their work, until you make some further changes.
$ git push origin --delete master
git ls-remote <remote>, or
git remote show <remote>
$ git push origin serverfix
This is a bit of a shortcut. Git automatically expands the
serverfixbranchname out to
If you’re using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication. By default it will prompt you on the terminal for this information so the server can tell if you’re allowed to push.
If you don’t want to type it every single time you push, you can set up a “credential cache”.
The simplest is just to keep it in memory for a few minutes, which you can easily set up by running
git config --global credential.helper cache.