Few more command , Git remote to see git remote repo , Git remove -v to see remote
repo urls
also git remote show origin
important if you created a branch on remote and want to move into that branch you
will if write git branch , you will not see that new branch in list but if you
write git brach remote , that will be in the list . To see at local end , Git
checkout branchname that is created . you can now move into that branch.
Follow this :- Always PUll before PUsh
Also when you want to merge anything to anybranch , that should be your active
branch.
Origin means GitHub or Remote
if you want to see branches , git branch , if you want to check respective remote ,
git branch -vv
note:- Suppose you and john are woking in same branch and john commit before you
and when you commit you will be told that your branch is 1 commit behind
so your comit will be rejected so what you would do is take pull but pull
basically take latest changes and merge your changes and created a new unnecessary
commit. So what you should do instead Git pull --rebase. if you get conflict just
abort rebase and take normal pull follow other steps to resolve conflict. Git pull
rebase what it will do it will take your commit and put is aside this command will
do the git pull and then put your commit back on top .
MERGE conflict :-
Pick animation from this video when make video on merge:-
https://www.youtube.com/watch?v=DloR0BOGNU0&t=34s
Important :- if you dont want to loose anything nd not want to resolve conflict
just do git merge --abort, everything will be as it is .
REbase : = if you already pushed your feature brach then don't rebase it so before
rebase just check git branch -a to see all your remote branches if you find
feature remote branch listed tehre don't rebase. ohteriwe safely rebase it .
To check all shortcuts keys on GitHub press shift+?
Please note we can resolve conflict manually and if we dont want to resolve we can
do git merge --abort as well
you can also check using Git diff as well instead of open file .
After download Gitbash
check log from other brnachif you are in main , git log nav-bar
Misc commands :- git --version and clear to clear the content in terminal and ls
(ls -a) to list down all files in a folder
to check current project folder pwd its present working directory
to check remote origon - git remote -v
to check which branch we are in :- git branch
to rename any branch suppose from master to main :- git branch -M Newname
to check all logs :- git log --oneline
git checkout name to move across branches
To create new branch , git branch branchname , git switch branchname ,git checkout
-b branchname , git checkout -c branchname
I want to merge something in me it means i should be on that branch in which i want
to merge
we can tell git that we will always push on origon main so we can set upstream with
-u option with push command next time you can avoid
writing "origon main" git push -u origon main next time just git push
Command 1:- here we are specifying in which account we want to change when we move
our changes to GitHub which username we want to show there with changes and also
email id we use on GitHub (it should be same as we used on GitHub)
Git config user.name AjayKumar
we can also use git config --list to see what we configure
Command 2:- Git config user.email "ajaykumar@gmail.com"
command 3:- we will create gitignore file
touch .gitignore
command 4:- All files are intialized
git init
command 5;-make all file ready (with this command all file moves to staging area
from working directory) Please note staging area is located in git folder .
Git add .
Command 6:- Now we will use commit to move changes or files from staging area to
Local repository -local repository is lies in git folder itself.
Git commit -m "this is message should be added with each commit"
command 7 :
_ now we have to move from local repository to Remote Repository using Push
before that let us check status
git status
command 8 :- Before pushing change we have to tell where these local repository
files will be moved so we have to configure remote repisotry
Git remote add origon GitURL
with above command now our project folder is connected with Repository
command 9 :_
Git push origin Master
Now with this all our files are moved to Git repository (remote)
command 10 : = suppose we don't have code on local and we have to access from a
remote repo for which we have GitHub URL or copy GitHub repo to our local
Git clone <GitHub Repo url>
command 11 :- GIT BRANCH TO CHECK BRANCH
TO RENAME A BRANCH GIT BRANCH -M NEWBRANCHNAME
Command 12:- tO MOVE TO ANOTHER BRANCH GIT CHECKOUT <BRANCHNAMETOsWITCH>
command 13 but to create new branch Git checkout -b <newbranchName>
command 14:= to delete branch :- git branch -d <branchname>
command 15 :- to move changes to remote feature branch
git push origon feature1
command 16:- we are on feature 1 brach , we can check difference between main and
feature before pushing changes to main branch
Git diff main
commdnd 17 :-Git merge main ( for merge feature branch to main branch) > this
can also be done through PR request on GitHub as well
command 18 we have merged feature brach to remote repostiry , changes will nto be
at local repo main unless you pull changes.
Remote changesfroom remote to local repo: git pull origon main
command 19 merge conflict
Git merge main (as we are on feature branch)
we see a popup for conflicts .
Now we can manually or change by chooseing option to merge conflict.
Now add changes and commit using git commit to fhat file
to merge feature 1 with main Git merge feature 1
Undoing changes
command :-undo staged changes
Git reset filename this will reset all added staged
changes
oing same thing in above file
git reset
command :- reset recent changes
Git reset Head~1
Git reset <cmmmot hash> in many commits
git reset --hard ( change will be removed fom Git and working directory as well
FoRK:--
same repo with same setting it is rough copy, we can creae a copy
command 17 :- Git stash to remove/save changes stash is like stack .
git stash list to check list
command _ git stash pop (this delete the stash after getting back your
changes)
you use git stash apply with this latest stash changes will start to appear in
your working directory but it does not delete stash .
you can also drop the stash git stash drop stashname , to clear all stash -> git
stash clear
you can also create branch from stash :- git stash branch branchname
18 Tags
git tag chai
git tag list
you can attach it with commit id
git tag gchai s33r3lll
command 29 _> REbase to change the base of the brach .
Now I am creating a brach using switch
git switch -c 'Pinkmode'
Git graph to see the git graph
now let us move to master , git checkout master
now commit this using git add . and commit
Now I want ot merge master changes into pinkmode to using merge
git checkout pinkmode
git merge master
if you check log there will be one extra commit it will show , to avoid you have
rebase
you want to rebase in the branch -> mostly in the feature branch when rebase.
Git rebase master
now check log
commdn 29:- REflog
Git reflog more precise logs
command 30 Git reset --hard head@{~1}
commad git clean to remove all files untacked files
command :- use git pull rebase instead of git pull (get linear commit history)
command :- amend commit
command :0 to revert you can also use git checkout #commitnumber
command you can cfeate branch usng git checkout -b branchname
Important :- how to resolve merge conflict -> tehre is a standard process to it
1. check out to main branch git checkout main
2. PUll the latest changes from remove main branch (changes that your
friend merged before you)
Now your main remote and local branches are identical
Now you can safely checkout to your feature branch git checkout feature branch
we were earlier attenmpting to merge feature branch to main when conflict occure
and now we have to reverse by merge main branch to feature branch.
Now run the command :- git merge main this is to identify the problem , please
note you are in feature branch.
IN the IDE you get to see the conflicts.
manually you can choose which line to choose , but you hit resolve button and see
options
weather you want to chose their code your code , or some of your code or some of
his code.
After resolve commit and push changes.
Important :- git reset <commitnumber> changes after this commit remain in working
directory
git reset --soft <commit number> changes remain staged after that
commit number
git reset --hard <commit number> changed vanished away
But if you have nothing to hide want to keep history of the commits then we use
Revert instead of reset. you want to keep record of the commit youdid dont' want to
hide. It will show conflict that we have to merge and when we apply git add . to
then we have to use git continue as well to finalize the revert
co
Git Stash:- keep your active changes somewhere and get back , save staged and
unstaged changes without commiting that.
Git stash
later on after working on other task you can come back and then to get your code
back Git stash apply , it will ask stash name , use git stash --list to see all
stash name, you can use git stash apply stashname
Git Cherry pick > Git cherry-pick commit number (right now you are in master and
merging other brach changes)
multiple commit cherry pick git cherry-pick commit numerb 1 commit number 2
when conflict raise during cherry-pick , check git status to have more details
Now to fix first of all git cherry-pick abort
afer resolve conflict git add and commit
Now its easy we have to type git cherry-pick continue
Other kind of conflct when you have local changes whch you did not commit and
perform cherry pick it will give you error , where you stash your changes in main
and follow above steps.
To get your changes from stash , Git stash apply
Please note git cherry-pick -n (-n option is used when you want not commit just
want ot staged the cherry pick changes)
command :- Now Git show #commitnumber to have detail about any commit
----
when we fork a repository for community contribtion the original repostiroy is
known as Upstream.
note :- make a separate branch for hotfix from main, dont do it in your feature
branch.
Also you can create a patch branch from commit number using git checkout -b patch
now cherry pick the hotfix from john branch into this .
now merge patch branch into your feature branch.
rules for checry pick
1. don't cherry pick commits from other peoples branches
2.only cherry pick from orphaned branches
3.Always create a separate branch for critical hotfixes.
SQUASH commit -> if you have multiple changes in your branch and if you want to
combine 3 last commit into 1 commit in commit history , After open commit history
in Visual studio , select 3 commit and do Squash commit and then type a message. So
all 3 commit will be merged into single commit.
REwrite commit:- Suppose you commit some changes and now just want a simple change
and if you don't want another commit , So in visual studio Along with pressing
commit all , select the checkbox "Amend" , so there will be no new commit but this
change will be added to old commit.
CHERRY PICK:- suppose you fixed something in a branch hotfix and now want to move
this to master. commit this change in hotfix branch . From visual studio go to
branches from menu . Switch to master branch , now click on the commit you just did
by clicking on the hotfix branch and select Cherry pick. Now you will see the
commit in the history of master branch.
REvert/reset:- if you want to revert any commit , from branches, from the listing
commits of a branch , select any commit and select revert or reset.
REVERT allow undoing the changes introduced by a commit.
We revert a commit or a change , what if we want to revert many changes then RESET.
if I want to have 4th commit means want to remove last 3 commit ,
select 4th commit and chose reset , you will be asked keep changes or remove
changes , select one of option and do reset , This will remove lastest 3 commits.
RESET allow branch to reset of any previous commit.
also when we are reverting by going into "view branch history"in visual studio we
are basically creating another commit for reverting changes . Do push changes after
revert any commit . if changes are pushed already .
if our changes are at local (not pushed to remote) we can do reset instead of
Revert.
------------
Note:- don't foreget to check view branch history in visual studio .
gggggggggggggggggggggggggggggg
best practices
1. Use Meaningful Commit Messages
Best Practice: Write clear, concise, and descriptive commit messages.
Example: Instead of "Fixed bug," use "Fixes bug where user profile fails to load
after login."
Why it’s important: Good commit messages make it easier to understand the purpose
of each commit, which is essential for reviewing changes and tracking project
history.
2. Commit Often, But with Purpose
Best Practice: Commit your changes in logical chunks, and try to keep commits small
and focused.
Example: If you're adding a feature, make a commit for each logical change (e.g.,
UI change, function implementation, test cases) rather than a massive commit that
includes everything.
Why it’s important: Small, frequent commits make it easier to review, understand,
and track changes, and can also help in easier rollback to specific versions.
3. Use Branches for Feature Development
Best Practice: Create separate branches for each feature or bug fix, and avoid
working directly on the main or master branch.
Example: Use descriptive names like feature/add-login-page or bugfix/fix-crash-on-
startup.
Why it’s important: This keeps your main branch clean and stable and allows for
parallel development without conflicts. It also makes it easier to test and review
changes in isolation.
4. Rebase Before Merging
Best Practice: Before merging a feature branch back into main, rebase it on top of
the current main branch.
Example: git checkout feature/add-login-page && git fetch origin && git rebase
origin/main
Why it’s important: Rebasing ensures a linear history and prevents unnecessary
merge commits that clutter the project history. It makes the history cleaner and
easier to understand.
5. Resolve Conflicts Early
Best Practice: If conflicts arise during merging or rebasing, resolve them as soon
as possible.
Why it’s important: Delaying conflict resolution can lead to more complex and
harder-to-resolve conflicts as the codebase evolves, slowing down the process.
6. Use Pull Requests (PRs) for Code Review
Best Practice: Always create a pull request for your changes and request code
reviews from your teammates before merging.
Why it’s important: PRs facilitate collaboration and ensure code quality by
allowing others to review the code, suggest improvements, and catch bugs.
7. Keep Your Branches Up to Date
Best Practice: Regularly pull the latest changes from the main branch into your
feature branches.
Why it’s important: This minimizes merge conflicts and ensures that your feature or
bug fix is always compatible with the most up-to-date codebase.
8. Avoid Committing Sensitive Information
Best Practice: Never commit sensitive data like passwords, API keys, or
configuration files containing secrets.
Why it’s important: Committing sensitive information can expose it to anyone with
access to your repository, leading to security risks.
9. Use .gitignore Properly
Best Practice: Maintain a .gitignore file to exclude unnecessary files from being
committed (e.g., build files, IDE configuration files, or dependencies).
Why it’s important: This ensures that only relevant files are tracked in your Git
history and prevents unnecessary bloat.
10. Use Tags for Releases
Best Practice: Use tags to mark release versions or significant milestones.
Example: git tag v1.0.0 for the first major release.
Why it’s important: Tags provide a clear snapshot of the project at a specific
point in time, making it easy to reference stable releases and roll back if needed.
11. Keep the Commit History Clean
Best Practice: Avoid unnecessary or "WIP" (work in progress) commits in your
feature branches.
Why it’s important: A clean, meaningful commit history helps others understand the
changes better, and a well-maintained history is easier to navigate.
12. Automate with Git Hooks
Best Practice: Use Git hooks to automate tasks such as running tests before
committing or ensuring commit messages follow a consistent format.
Why it’s important: Automating processes like testing or checking commit
conventions reduces errors and ensures the team follows agreed-upon standards.
13. Keep Repositories Modular
Best Practice: If your project grows large, consider splitting it into smaller,
more manageable repositories (monorepo vs polyrepo).
Why it’s important: It can simplify the management of dependencies, deployment, and
scaling, especially in large-scale projects.
14. Use Git Submodules for External Dependencies
Best Practice: Use Git submodules if your project depends on another Git repository
that is being developed independently.
Why it’s important: It allows you to include and update external repositories
within your project while keeping them separate from your main codebase.
15. Understand Git’s Merge Strategies
Best Practice: Understand different merge strategies (e.g., merge, rebase, fast-
forward) and use the one that best fits the situation.
Why it’s important: The strategy you choose affects the project’s history and can
make the workflow more efficient.
16. Use git log and git diff Effectively
Best Practice: Use git log to view project history and git diff to see changes
before committing or merging.
Why it’s important: These commands allow you to review your changes in depth and
ensure that no unnecessary or unexpected changes are included.
17. Document Git Workflows
Best Practice: Document your team’s Git workflow (e.g., feature branches, commit
message guidelines) and ensure everyone adheres to it.
Why it’s important: Clear guidelines make collaboration easier and prevent
confusion, especially in larger teams or projects.
18. Use Git Aliases
Best Practice: Set up Git aliases to shorten commonly used commands.
Example: git config --global alias.co checkout will allow you to use git co instead
of git checkout.
Why it’s important: Aliases save time and reduce the chance of making syntax errors
with long commands.
19. Don’t Rebase Public Branches
Best Practice: Avoid rebasing branches that have been shared with others or have
been pushed to public repositories.
Why it’s important: Rebasing rewrites history, which can cause confusion and break
links to previous commits in shared branches.
20. Always Back Up Before Major Changes
Best Practice: Before making significant changes (like a big rebase or reset),
create a backup branch.
Why it’s important: This ensures you have a reference point to return to if
anything goes wrong.
21. Keep Feature Branches Short-Lived
Best Practice: Aim to keep feature branches as short-lived as possible. Merge them
back into main or develop as soon as the feature is complete.
Why it’s important: Long-lived branches can diverge significantly from the main
branch, leading to difficult merges and conflicts. Short-lived branches reduce
complexity and ensure easier integration.
22. Use Branch Naming Conventions
Best Practice: Establish a clear naming convention for branches (e.g., feature/,
bugfix/, hotfix/, release/).
Example:
feature/add-search-bar
bugfix/fix-header-alignment
hotfix/resolve-crash-on-startup
Why it’s important: Consistent naming helps all team members quickly understand the
purpose of each branch and reduces confusion.
23. Avoid Force Push (git push --force) on Shared Branches
Best Practice: Avoid using git push --force (especially on shared branches like
main, develop, etc.) as it can rewrite history and cause issues for other
contributors.
Why it’s important: Force-pushing can overwrite changes made by others, leading to
data loss, confusion, and difficulties in collaboration.
24. Use git stash for Temporary Changes
Best Practice: If you're working on something and need to switch branches, use git
stash to temporarily store your changes before switching.
Example: git stash and then git stash pop after switching branches.
Why it’s important: This prevents you from committing incomplete or irrelevant
changes and allows you to switch branches without losing progress.
25. Use git cherry-pick for Specific Commits
Best Practice: When you need to apply specific commits from one branch to another,
use git cherry-pick to pull in those changes without merging entire branches.
Why it’s important: This allows you to isolate and bring in only the necessary
changes while avoiding unintentional merges or conflicts.
26. Implement Git Flow or Trunk-Based Development
Best Practice: Use established Git workflows such as Git Flow (feature branches,
releases, hotfixes) or Trunk-Based Development (direct commits to main with feature
toggles).
Why it’s important: A standardized workflow provides structure and reduces
confusion about where and how to commit changes, especially in large teams.
27. Review Pull Requests (PRs) Thoroughly
Best Practice: Encourage thorough code reviews for every PR, focusing not just on
correctness but also on readability, maintainability, and adherence to project
standards.
Why it’s important: Code reviews improve code quality, promote knowledge sharing,
and catch potential bugs or issues early.
28. Use CI/CD Integration with Git
Best Practice: Set up Continuous Integration (CI) and Continuous Deployment (CD)
pipelines to automatically run tests, build the project, and deploy it when changes
are made to certain branches.
Why it’s important: Automated pipelines ensure that code is always tested and ready
for deployment, reducing the risk of bugs and ensuring consistent quality.
29. Keep Git History Clean with Squash Merging
Best Practice: Squash commits when merging feature branches so that your project
history remains clean and avoids having a cluttered commit history.
Why it’s important: Squashing commits before merging reduces noise in the commit
history and makes it easier to understand the changes in each merge.
30. Use git reflog to Recover Lost Commits
Best Practice: In case you’ve lost a commit or accidentally performed a destructive
operation, use git reflog to recover previous states of the repository.
Why it’s important: git reflog allows you to see the history of your HEAD and
recover from mistakes like git reset --hard.
31. Avoid Using Large Binary Files in Git
Best Practice: Avoid storing large binary files in Git. Use Git LFS (Large File
Storage) or external file hosting solutions for large assets (like images, videos,
etc.).
Why it’s important: Large binary files can make the repository size grow quickly
and impact performance. Git LFS handles large files efficiently and prevents
repository bloat.
32. Be Mindful of Merge Conflicts and Learn Conflict Resolution
Best Practice: Familiarize yourself with how to resolve merge conflicts
effectively. Communicate with your team if conflicts are complex or time-consuming.
Why it’s important: Knowing how to resolve conflicts efficiently can save time and
avoid frustration during development, especially when multiple developers are
working on the same areas of code.
33. Use Git Hooks for Pre-Commit or Pre-Push Checks
Best Practice: Set up Git hooks (e.g., pre-commit, pre-push) to automate checks
such as running linters, tests, or formatting scripts before code is committed or
pushed.
Why it’s important: These hooks ensure that the code is well-formed, passes basic
tests, and adheres to coding standards before it enters the codebase.
34. Document Git Usage Guidelines for Your Team
Best Practice: Document Git workflows, branch naming conventions, commit message
guidelines, and code review procedures for your team.
Why it’s important: Having clear documentation ensures consistency across the team
and avoids confusion, especially when onboarding new team members.
35. Use Git Submodules for External Repositories
Best Practice: If you are working with external libraries or dependencies that are
themselves managed with Git, consider using submodules.
Why it’s important: Submodules allow you to keep track of external repositories and
their versions within your own project without duplicating code.
36. Use git bisect to Find Bugs Efficiently
Best Practice: Use git bisect to perform a binary search on your commit history to
identify the commit that introduced a bug.
Why it’s important: git bisect can dramatically speed up the process of finding
bugs by narrowing down the problematic commit in your repository’s history.
37. Tag Important Commits
Best Practice: Use Git tags to mark specific commits, such as releases or important
milestones, and refer to them easily.
Why it’s important: Tags provide a simple way to reference important points in your
project’s history without needing to search through commits manually.
38. Use Pull Requests for Non-Technical Contributions
Best Practice: Even for non-technical contributions (like documentation changes),
consider using pull requests so that everyone in the team can review changes.
Why it’s important: This ensures quality control and helps track all changes to the
repository in a centralized manner.
39. Use git log Filters to Track Changes
Best Practice: Use git log with filters (e.g., git log --author=<name>, git log --
since=<date>) to easily find and review changes made by specific people or within
specific time periods.
Why it’s important: This helps you keep track of changes and stay organized when
reviewing historical commits.
40. Use git blame to Understand Line-by-Line Changes
Best Practice: Use git blame to track changes made to specific lines of a file and
understand why a particular change was made.
Why it’s important: git blame helps trace the origin of specific lines of code and
provides context for modifications or bug investigations.
