Set default editor:

$ ­git­config -­global core. Editor notepad++

git init initilaizes empty repository.
.gitignore file contains folders and paths that Git will ignore. Example:

gdata/
atom/
.idea/
*.pyc

To stage and commit your changes:

Git add .
Git commit –m “your comment”

To see your config settings:

$ git config --list
core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
user.name=morpheus
user.email=
core.editor=notepad++
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly

If you modify a file after you run git add, you have to run
git add again to stage the latest version of the file:

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

Here is another example .gitignore file:

# a comment – this is ignored
*. a # no . a files
! lib. a # but do track lib. a, even though you' re ignoring . a files above
/TODO # only ignore the root TODO file, not subdir/TODO
build/ # ignore all files in the build/ directory
doc/*. txt # ignore doc/notes. txt, but not doc/server/arch. txt

If you want to see what you’ve staged that will go into your next commit, you can use git
diff –-cached. (In Git versions 1.6.1 and later, you can also use git diff –-staged, which may
be easier to remember.) This command compares your staged changes to your last commit:

It’s important to note that git diff by itself doesn’t show all changes made since your last
commit—only changes that are still unstaged. This can be confusing, because if you’ve staged
all of your changes, git diff gives you no output.
Thus git diff = difference between latest and staged
git diff --cached = difference between staged and committed

Although it can be amazingly useful for crafting commits exactly how you want them, the staging
area is sometimes a bit more complex than you need in your workflow. If you want to skip the
staging area, Git provides a simple shortcut. Providing the -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 rm *~
This command removes all files that end with ~. Now consider the mv command:

$ git mv file_from file_to

This is equivalent to running something like below:

$ mv README. txt README
$ git rm README. txt
$ git add README

To see a log of changes, run:

$ git log --pretty=format:"%h - %an, %ar : %s"
ca82a6d - Scott Chacon, 11 months ago : changed the version number
085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code
a11bef0 - Scott Chacon, 11 months ago : first commit

To see the logs of past two weeks, run:

$ git log --since=2.weeks

If you want to see which commits in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:

$ git log -- pretty=" %h: %s" - - author=gitster -- since="2008- 10- 01"
- -before="2008- 11- 01" - -no- merges - - t/

If you commit and then realize you forgot to stage the changes in a file you
wanted to add to this commit, you can do something like this:

$ git commit - m ' initial commit'
$ git add forgotten_file
$ git commit - - amend

All three of these commands end up with a single commit—the second command
replaces the results of the first.

to undo your pending changes:

$ git checkout -- FILE

to make backup on f: drive:
1. cd to f: from cmd.exe
2. run “c:Program Filesgitbinsh.exe” –login -i
3. mkdir my_repository
4. cd my_repository
5. git init –bare
6. now cd to the directory in c:
7. git push –mirror “f:my_repository” (execute this command periodically to make backups)
Counting objects: 211, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (200/200), done.
Writing objects: 100% (211/211), 124.92 KiB, done.
Total 211 (delta 108), reused 0 (delta 0)
To f:git
* [new branch] master -> master

Uploading local repository to BitBucket

1. Create empty repository on bitbucket
2. git remote add bb https://URL. this adds a remote repository named bb
3. git push bb master. this pushes the master (which is the local repo) to bb
http://git-scm.com/book/en/Git-Basics-Working-with-Remotes
You are set.
then to push updates just do:
git push bb master

To push to non-master branch use:

git push <remote> <local-branch>:<remote-branch>

e.g., git push bb master:pro

To see list of files in a commit use:

git diff-tree --no-commit-id --name-only -r 8561998a

To delete remote branch

$ git push origin --delete <name-of-remote-branch>

Adding a file and ignoring it afterwards

e.g., you want to commit launch.json but want to ignore change to it afterwards (e.g., you add a password). once you have committed a file adding it to .gitignore will not ignore it. But you can run:

git update-index --assume-unchanged .vscode/launch.json

and as the command says git will assume file has not changed (even though it has). to undo this run:

git update-index --no-assume-unchanged .vscode/launch.json

show how many commits your feature branch is ahead of main

git rev-list --left-right --count main...feature-branch