git tutorial

 these are just notes for study https://git-scm.com/book/en/v2

git configs location 

1. [path]/etc/gitconfig =:> applied to every user

2.  ~/.gitconfig or ~/.config/git/config  =:> 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

identity setup:: 

$ git config --global user.name "John Doe"
$ git config --global user.email [email protected] 

set editor


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

$mkdir project

$cd project

cd to desired dir and run ::

$git init

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 https://github.com/kzwkt/dellconfig

clones to $PWD/dellconfig 

$ git clone https://github.com/kzwkt/dellconfig testclone

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 

  $git status -s 

#short status ??= untracked A=staged M=modified

this give status of files

Ignoring Files

create .gitignore

The rules for the patterns you can put in the .gitignore file are as follows:

• Blank lines or lines starting with # are ignored.

• 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/z, a/b/z, a/b/c/z, and so on.

example 

 #ignore any files ending in “.o” or “.a” 

*.[oa]  

#ignore all files whose names end with a tilde (~) 

*~  

see https://github.com/github/gitignore

Viewing Your Staged and Unstaged Changes

#to view excat changes that are unstaged 

$git diff

#compares your staged changes to your last commit 

$git diff --staged 

#to see what you’ve staged so far (--staged and --cached are synonyms): 

$ git diff --cached  

 #view in external tool

$git difftool 

#list available difftool 

$git difftool --tool-help 

 

Committing Your Changes

$git commit

#will launch $EDITOR  i.e your fav editor or that set in  git config --global core.editor someeditor

$git commit -v

#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

 

a option to the git commit command makes Git automatically stage every file that is already 

tracked before doing the commit, letting you skip the git add part: 

$ git commit -a -m 'Add new benchmarks' 

Removing Files

 git rm command  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 \*~

Moving Files

$ 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 mv command.The only real difference is that git mv is one command instead of 

three 

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/

 

Table 1. Useful specifiers for git log --pretty=format

Specifier	Description of Output
%H	Commit hash
%h	Abbreviated commit hash
%T	Tree hash
%t	Abbreviated tree hash
%P	Parent hashes
%p	Abbreviated parent hashes
%an	Author name
%ae	Author email
%ad	Author date (format respects the --date=option)
%ar	Author date, relative
%cn	Committer name
%ce	Committer email
%cd	Committer date
%cr	Committer date, relative
%s	Subject

Undoing Things

git commit --amend

If you want to redo  commit, make the additional changes you forgot, stage them, and commit

again using the --amend option 

ex:: 

$ 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

The git status command 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 reset for git >2.23.0

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

git remote 

show shortname 

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 clone command implicitly adds the origin remote for you

run 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 fetch command 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 git pull 

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/master is now at paul/master. 

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. 

Tagging

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

Annotated Tags

git tag -a v1.4 -m "my version 1.4"

The -m specifies 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

Lightweight Tags

To create a lightweight tag, don’t supply any of the -a, -s, or -m options, just provide a tag name:

 

$ git tag v1.4-lw

$ git show v1.4-lw

Tagging Later

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

Sharing Tags

 git 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-tags only annotated tags will be pushed to the remote.

Deleting Tags

$ git tag -d v1.4-lw

The first variation is git push <remote> :refs/tags/<tagname>:

$ git push origin :refs/tags/v1.4-lw

second method 

$ 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'

Aliases

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

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.

 


 If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.

 A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you start making commits, you’re given a master branch that points to the last commit you made. Every time you commit, the master branch 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 HEAD. 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 master. The git branch command only created a new branch — it didn’t switch to that branch.

 

$ git log --oneline --decorate

Switching Branches

$ git checkout testing

This moves HEAD to point to the testing branch.

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 -c flag stands for create, you can also use the full flag: --create.

• 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 hotfix merge 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 hotfix branch, 

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.  

git status

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>

 git add

to mark as resolved and git commit

git mergetool,

for graphical resolution

git status

Branch Management

 

git branch 

list branch

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 -d will 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

 

The main branch is present on the remote. However, the old master branch is still present on the remote. Other collaborators will continue to use the master branch as the base of their work, until you make some further changes.

 

$ git push origin --delete master

 

Remote Branches

git ls-remote <remote>, or git remote show <remote>

$ git push origin serverfix

 This is a bit of a shortcut.
Git automatically expands the serverfix branchname out to refs/heads/serverfix:refs/heads/serverfix

 

 

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.