Official Account:

Personal Account:

sudo apt install git

By default, git config will write to a local level if no configuration option is passed. Local level configuration is applied to the context repository git config gets invoked in. Local configuration values are stored in a file that can be found in the repo's .git directory: .git/config

Global level configuration is user-specific, meaning it is applied to an operating system user. Global configuration values are stored in a file that is located in a user's home directory. ~ /.gitconfig on unix systems and C:\Users\.gitconfig on windows

System-level configuration is applied across an entire machine. This covers all users on an operating system and all repos. The system level configuration file lives in a gitconfig file off the system root path. $(prefix)/etc/gitconfig on unix systems. On windows this file can be found at C:\Documents and Settings\All Users\Application Data\Git\config on Windows XP, and in C:\ProgramData\Git\config on Windows Vista and newer.

Thus the order of priority for configuration levels is: local, global, system. This means when looking for a configuration value, Git will start at the local level and bubble up to the system level.

git config --global user.email "[email protected]"
git config --global user.name "Your Name"
git config --global color.ui true

git config --list

Compared to SVN, the git init command is an incredibly easy way to create new version-controlled projects. Git doesn’t require you to create a repository, import files, and check out a working copy. Additionally, Git does not require any pre-existing server or admin privileges. All you have to do is cd into your project subdirectory and run git init, and you'll have a fully functional Git repository. Transform the current directory into a Git repository.

This adds a .git subdirectory to the current directory and makes it possible to start recording revisions of the project. Create an empty Git repository in the specified directory. Running this command will create a new subdirectory called containing nothing but the .git subdirectory. If you've already run git init on a project directory and it contains a .git subdirectory, you can safely run git init again on the same project directory. It will not override an existing .git configuration.

git init

You'll run the command "git status" quite often. It's the same as calling a bank administrator to check if your things arrived or if anything has been moved to a different vault.

git status

Now we can answer the question, "Why does Git need to track files?" Before we commit any files to a local repository, Git wants to know what those files are. Git only knows what to commit when it's tracking files.

If there are no files in the root directory yet, Git shows that there's nothing to commit. Our safe deposit box (repository) is empty. To do anything further, we need to populate the root folder with at least one file. We've added my-new-file.txt to the root directory. Now we can move on to the next step.

When you run "git status" once more (assuming you've added a file to the project's root directory), you'll get a different output. Note: the "Untracked files" message with the file "my_new_file.txt". Git conveniently informs us that we've added a new file to the project. But that isn't enough for Git. As Git tells us, we need to track "my_new_file.txt". In other words, we need to add "my_new_file.txt" to the staging area.

The git add command adds new or changed files in your working directory to the Git staging area. git add is an important command - without it, no git commit would ever do anything. Sometimes, git add can have a reputation for being an unnecessary step in development. But in reality, git add is an important and powerful tool. git add allows you to shape history without changing how you work.

Let's say you want to move some of your valuable effects to a lock box, but you don't know yet what things you'll put there. For now, you just gather things into a basket. You can take things out of the basket if you decide that they aren't valuable enough to store in a lock box, and you can add things to the basket as you wish. With Git, this basket is the staging area. When you move files to the staging area in Git, you actually gather and prepare files for Git before committing them to the local repository.

git add <file-name>

git add my_new_file.txt

That's it; you've added a file to the staging area with the "add" command. Don't forget to pass a filename to this command so Git knows which file to track.

But what has this "add" command actually done? Let's view an updated status (we promised that you'll often run "git status", didn't we?):

The status has changed! Git knows that there's a newly created file in your basket (the staging area), and is ready to commit the file.

What if you create or change several files? With a basket as your staging area, you have to put things into the basket one by one. Committing files to the repository individually isn't convenient. What Git can do is provide alternatives to the "git add " command.

Let's assume you've added another three files to the root directory: my-file.ts, another-file.js, and new_file.rb. Now you want to add all of them to the staging area. Instead of adding these files separately, we can add them all together:

git add my-file.ts another-file.js new_file.rb

All you need to do is type file names separated by spaces following the "add" command. When you run "git status" once more to see what has changed, Git will output a new message listing all the files you've added:

Adding several files to the staging area in one go is much more convenient! But hold on a second. What if the project grows enormously and you have to add more than three files? How can we add a dozen files (or dozens of files) in one go? Git accepts the challenge and offers the following solution:

git add .

Instead of listing file names one by one, you can use a period – yes, a simple dot – to select all files under the current directory. Git will grab all new or changed files and shove them into the basket (the staging area) all at once. That's even more convenient, isn't it? But Git can do even better.

There's a problem with the "git add ." command. Since we're currently working in the root directory, "git add ." will only add files located in the root directory. But the root directory may contain many other directories with files. How can we add files from those other directories plus the files in the root directory to the staging area? Git offers the command below:

git add --all

The option "--all" tells Git: "Find all new and updated files everywhere throughout the project and add them to the staging area." Note that you can also use the option "-A" instead of "--all". Thanks to this simple option, "-A" or "--all", the workflow is greatly simplified.

Remember when we told you that you can take things out of your imaginary basket? Git can also take things out of its basket by removing files from the staging area. To remove files from the staging area, use the following command:

git rm --cached my-file.ts

In our example, we specified the command "rm", which stands for remove. The "--cached" option indicates files in the staging area. Finally, we pass a file that we want to unstage. Git will output the following message for us:

rm my_file.ts

Git is no longer tracking my-file.ts. In this simple way, you can untrack files if necessary. As an alternative to "rm --cached <filename>", you can use the "reset" command:

git reset another-file.js

You can consider "reset" as the opposite of "add".

• git add . stages new files and modifications, without deletions. The important point about git add . is that it looks at the working tree and adds all those paths to the staged changes if they are either changed or are new and not ignored, it does not stage any 'rm' actions.

• git add -u stages modifications and deletions, without new files. It looks at all the already tracked files and stages the changes to those files if they are different or if they have been removed. It does not add any new files, it only stages changes to already tracked files.

• git add -A stages all changes. It is a handy shortcut for doing both of those.

Let's start with a quick overview of committing to the Git repository. By now, you should have at least one file tracked by Git (we have three). As we mentioned, tracked files aren't located in the repository yet. We have to commit them: we need to carry our basket with stuff to the lock box. There are several useful Git commands to do (almost) the same: move (commit) files from the staging area (an imaginary basket) to the repository (a lock box).

There's nothing difficult about committing to a repository. Just run the following command:

git commit -m "Add three files"

To commit to a repository, use the "commit" command. Next, pass the "commit" command the "-m" option, which stands for "message". Lastly, type in your commit message. We wrote "Add three files" for our example, but it's recommended that you write more meaningful messages like "Add admin panel" or "Update admin panel".

Note that we didn't use the past tense! A commit message must tell what your commit does – adds or removes files, updates app features, and so on.

Once we've run "git commit -m 'Add three files'", we get the following output:

The message tells us that there have been three files added to the current branch, which in our example is the master or the main branch. The "create mode 100644" message tells us that these files are regular non-executable files. The "0 insertions(+)" and "0 deletions(-)" messages mean we haven't added any new code or removed any code from the files. We actually don't need this information; it only confirms that the commit was successful.

There will be times when you'll regret committing to a repository. Let's say you've modified ten files, but committed only nine. How can you add that remaining file to the last commit? And how can you modify a file if you've already committed it? There are two ways out. First, you can undo the commit:

git reset --soft HEAD^

As you may recall, the "reset" command is the opposite of the "add" command. This time, "reset" tells Git to undo the commit. What follows "reset" is the "--soft" option. The "--soft" option means that the commit is canceled and moved before HEAD. You can now add another file to the staging area and commit, or you can amend files and commit them.

To understand what that "HEAD" thing represents, recall that we work in branches. Currently we're in the master branch, and HEAD points to this master branch. When we switch to a different branch later, HEAD will point to that different branch. HEAD is just a pointer to a branch:

What you see in the image is that each dot represents a separate commit, and the latest commit is at the top of the branch (HEAD). In the command "git reset --soft HEAD^" the last character "^" represents the last commit. We can read "git reset --soft HEAD^" as "Undo the last commit in the current branch and move HEAD back by one commit."

Instead of resetting the HEAD and undoing the last commit, we can rectify a commit by using the "--amend" option when committing to a repository. Just add the remaining file to the staging area and then commit:

git add file-i-forgot-to-add.html

git commit --amend -m "Add the remaining file"

The "--amend" option lets you amend the last commit by adding a new file (or multiple files). Using the "--amend" option, you can also overwrite the message of your last commit.

Think of this command in this way: you took out the top stack of papers from the drawer and "amended" them by simply unstapling the bunch of papers, adding another paper, file-i-forgot-to-add.html, on top and rewriting the message on the "commit" paper.

git remote add origin <Git repository URL>

git push -u origin master

// Clone existing project 6. git clone

// Once project clone in local then traverse to project folder 7. cd

// To take latest changes 8. git pull

// If there are branches and want to get all data then fetch 9. git fetch --all

// Check how many branches are present in Git 10. git branch 11. git branch -a

// Create new branch 13. git checkout -b --no-track

// Navigate exiting branch 14. git checkout

// Navigate parent branch 15. git checkout

// from any branch to master 16. git checkout master

// Merge code of Branch-1 with Branch--2 16. git checkout Branch-1 17. git merge Branch-2

//Check status of code if any new updates is in code 18. git status //Add changes and then commit code then push on specific branch // Push changes in current branch: - 19. git push origin //Delete Branch 20. git branch -d

//Delete commit msg git commit --amend -m "New commit message"

git grep "regex"

git branch -a

git branch -r

make sure you don't use origin

git fetch
git checkout branchName

first create a branch

git checkout -b <branchName>

Create a new branch from an existing branch

git checkout origin/branchName -b newBranchName

Then push your new branch to the repo

git push origin <branchName>

AKA Recover a deleted branch

git checkout -b <branch> <sha>

git reset --hard

git reset 56e05fced

git checkout HEAD -- /somePath/file.txt

git checkout -- <file>

git checkout origin/branchName  -- fileName.txt

git reset --hard HEAD~1

git reset --soft HEAD~1

git clean -f

git clean -f -d

git clean -fxd {dir_path}

git commit /folderToCommit -m 'commit msg'

git branch -a
git branch -r

git branch --contains <commit>

git log --pretty=format:"%h - %cr (%an) %s" --graph

git fetch
git merge origin/master

a shortcut to this is. They are both the same

git pull origin master

or, if it's a busy repo.

git pull --rebase <remote name> <branch name>

git diff --name-only --diff-filter=U
grep -lr '<<<<<<<' .

git mergetool -t opendiff

git pull -s recursive -X theirs origin ra

git log -m -1 --name-only

git diff --name-status master..branchName > changelog.txt

Get the SHA of the last commit on the branch.

git checkout -b newbranchname 56e05fced

git stash save "My changes."

git stash list

git stash apply stash@{1}

git push origin --delete <branchName>

git branch -d <branchName>

git cherry -v develop mybranch

This reverts the commit with a new commit.

First get the commit sha.

git revert -m 1 <commit-hash> 
git commit -m "Reverting the last commit which messed the repo."
git push -u origin master

find . -maxdepth 1 -mindepth 1 -type d -exec sh -c '(echo {} && cd {} && git status -s && echo)' \;

Save the results to a file.

find . -maxdepth 1 -mindepth 1 -type d -exec sh -c '(echo {} && cd {} && git status -s && echo)' \; > gitreport.txt

run git fetch -p this removes the remote references.

run git branch -vv

then run the following script

git fetch -p && for branch in `git branch -vv | grep ': gone]' | awk '{print $1}'`; do git branch -D $branch; done

keywords: prune