Hello everyone!
This blog post is going to contain all the git commands with its use cases for quick lookup.
Without further ado, let's jump into it.
BASICS
-
git init- to initialise the repository for git to track it. -
git add <filename>- adds the untracked file to stage. -
git add <file-1> <file-2> <file-3>- adds multiple files based on the specified file names to stage. -
git add .- adds all the untracked files to stage. -
git restore -stage <filename>- unstage the i.e it moves to untracked files list. -
git stash- moves both the (un-committed) staged and unstaged files to stash (like backstage) for cleaner working directory. -
git stash pop- moves back all the files in stash area. -
git stash clear- clears the files in stash i.e permanently deletes. -
git commit -m <title> -m <description>- commits the staged/tracked files with the corresponding commit message and description. -
git log- public record of commit history for a branch. -
git reflog- private record, saved locally used for recovering deleted branches. -
git reset <commit-id>- resets the head to the commit id mentioned and the removed commits are pushed to unstaged area. -
git reset --hard <commit-id>- resets the head to the commit id mentioned and deletes the changes of above commits permenantly. -
git revert <commit-id>- While git reset does this by moving the current head of the branch back to the specified commit, thereby changing the commit history, git revert does this by creating a new commit that undoes the changes in the specified commit and so does not change the history. 14.git push origin <remote-branch>- pushes your commits to remote repository, thats mentioned in the command. -
git push origin <remote-branch> -f- force push required when remote branch has some commits which aren't present/removed in local(eg: with git reset). - When working with forked projects, we need to fetch upstream commits -
git pull upstream developThis creates an extra commit. -
git rebase -i <commit-id>- Squashing your commits above a particular commit id(you can either pick or squash) -
git commit --amend -no-edit- adds the staged files to previous commits without generating a new commit. -
git commit --amend- adds the staged files to previous commit whilst providing an option to edit the previous commit. This and the above are very helpful when some logical step is missed in the previous commit.
Prefer rebase over merge to pull remote changes to avoid merge commits -
-
git remote -v- displays all the remote urls attached to the local repository. -
git remote add <remote-name> <remote-url>- connecting your local git repository with the remote repository hosted on Github with the remote name.-
<remote-name>is generally origin for the repo cloned from github. It basically depicts the repository that we want to connect to. - A repository might have multiple forks in which one of them can be cloned to the local repository.
-
-
In order to pull the changes from upstream repo into the fork -
git pull --rebase <remote-name> <feature-branch>- this pulls and rebases the remote branch of upstream repo without making an extra commit on feature/develop branch of forked repo. Feature branches don't need to track merge commits.
- resolve the merge conflicts in the process of rebase if exists.
- use
git rebase --continueonce merge conflicts are resolved for a particular commit to continue further. - use
git rebase --abortfor aborting the rebasing.
If you need to squash any duplicate commits, use
git rebase -i HEAD~Norgit rebase -i <commit-id>.DO NOT FORGOT to FORCE PUSH the commits that are squashed or amended.
git push origin develop -f
QUESTION
And there's some famous question/doubt everyone has on their mind when starting off with git/github:
Why is a git 'pull request' not called a 'push request'?
"Push" is you forcing the changes being present in the target repository (git push).
"Pull" is the target repository grabbing your changes to be present there (git pull from the other repo).
- A "pull request" is you requesting the target repository to please grab your changes.
- A "push request" would be the target repository requesting you to push your changes.
Always write better commit messages
- Commit history is the index.
- Writing meaningful, logical and verbose commit messages allows others to understand the task or story that the PR solves.
- Prepend the commit message with its the type like feat, chore, fix, test, docs, refactor etc. https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/
- squash all duplicate commits so that the master branch contains clean commit history.
Thank you!
Top comments (0)