Set default editor:
$ gitconfig -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 rungit 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. (In Git versions 1.6.1 and later, you can also use
diff –-cachedgit 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 stagedgit 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
Change URL of remote repository such as the origin
git remote set-url origin git@github.com:username/repository.git
Updating your remote URL is only the first step. To get your local environment fully in sync with the new server state, you usually need to perform a “handshake” to verify the connection and update your local tracking references.
Here is how you can sync and refresh effectively:
1. Verify the Change
First, make sure the URL actually updated correctly.
git remote -v
2. Fetch the New Data
Running a fetch is the most important part. This tells your local Git to reach out to the new URL, see what branches exist there, and update its internal map of the remote.
git fetch --all --prune
--all: Grabs updates from all remotes.--prune: This is the “refresh” part. It deletes local references to branches that no longer exist on the remote (cleaning up the “ghost” branches).
3. Re-link Your Branches (If Needed)
If you changed the remote’s name (e.g., from origin to upstream), or if you’ve moved to a completely different repository where the branch names don’t match, you might need to reset the “upstream” tracking for your current branch:
git branch --set-upstream-to=origin/main main
4. Pull the Latest
Now that the connection is refreshed, pull down the actual files:
git pull
Troubleshooting “Authentication Failed”
Since you changed the URL, your computer might still be trying to use old credentials stored in your keychain or credential manager.
- If using HTTPS: You may be prompted for a new Personal Access Token (PAT).
- If using SSH: Ensure your public key is added to the settings of the new host (e.g., the new GitHub or GitLab account).
Find size of untracked files
You can compute it from the index (what’s staged) or from what would be committed if you staged everything.
1) After you stage, get the exact size that will be committed
git add -A
git ls-files -s -z \
| cut -d' ' -f2 \
| tr '\0' '\n' \
| git cat-file --batch-check='%(objectsize)' \
| awk '{sum += $1} END {printf "staged blob bytes: %d (%.2f MiB)\n", sum, sum/1024/1024}'
Notes:
- This sums the sizes of the blob objects for the staged content (i.e., what Git will store), not “working tree file sizes”.
- This is usually what you want if your concern is “how big is this commit in Git terms?”
2) Without staging: estimate size of “everything currently untracked” (your current case)
Since your git status shows only untracked files, you can sum their on-disk sizes directly:
GNU/Linux:
du -sb .gitignore README.md dotnetipl paintings-csharp paintings-swift paintings-winforms python-scripts wordpress \
| awk '{sum += $1} END {printf "working-tree bytes: %d (%.2f MiB)\n", sum, sum/1024/1024}'
macOS / BSD (no -b):
du -sk .gitignore README.md dotnetipl paintings-csharp paintings-swift paintings-winforms python-scripts wordpress \
| awk '{sum += $1} END {printf "working-tree KiB: %d (%.2f MiB)\n", sum, sum/1024}'
3) If you want a one-liner that matches “what would be committed if I staged everything”, but without writing to the index
You can use Git’s pathspec from git status --porcelain and du:
git status --porcelain -z \
| awk -v RS='\0' 'substr($0,1,2)=="??"{print substr($0,4)}' \
| tr '\n' '\0' \
| xargs -0 du -sb 2>/dev/null \
| awk '{sum+=$1} END {printf "untracked bytes: %d (%.2f MiB)\n", sum, sum/1024/1024}'