Write The Following Commands
git config --global user.name "Gihub User Name"
git config --global user.email "Github Email"
git config --list
Command | Description |
---|---|
👉 git init | ✍️ Initialize a new repository |
git init |
|
👉 git clone | ✍️ Clone a remote repository |
git clone https://github.com/example/repo.git |
|
👉 git add | ✍️ Stage file changes |
git add file.txt |
|
git add . |
|
👉 git commit | ✍️ Commit changes with a descriptive message |
git commit -m "Added new feature |
|
👉 git status | ✍️ Check repository status |
git status |
|
👉 git push | ✍️ Push committed changes to a remote repository |
git push origin main |
|
👉 git pull | ✍️ Fetch and merge changes from a remote repository |
git pull origin main |
|
👉 git branch | ✍️ List of all branches |
git branch |
|
👉 git checkout | ✍️ Switch to a different branch |
git checkout new-feature |
|
👉 git merge | ✍️ Merge a branch into the current branch |
git merge new-feature |
|
👉 git log | ✍️ View git commit history |
git log |
|
👉 git remote | ✍️ Add remote repository |
git remote add upstream https://github.com/upstream/repo.git |
|
👉 git diff | ✍️ Show differences between files |
git diff file1.txt file2.txt |
|
👉 git reset | ✍️ Unstage a file |
git reset file.txt |
git init
git add .
git commit -m "Commits Names"
git branch -M main
git remote add origin " Git Repository Link"
git push -u origin main
git push origin master --force
git push --set-upstream origin main
git clone "RepositoryLink"
git clone https://github.com/link.git
git clone "RepositoryLink" "Location Path"
git clone https://github.com/link.git ./Test
git init
to that foldergit clone https://github.com/example/example.git ./
cd "Git Repository Name"
git remote -v
pwd
git status
git add text.txt
git commit -m "Commit Name"
git push"
git push -f"
git status
git add "file name"
git status
git reset -- "file name"
git log
git checkout "Hash Code"
🔛 Branching Using Git Bash👇
git branch
git branch New_Branch_Name
git checkout New_Branch_Name
git checkout main
git branch -m new-name
git branch -d branch_name
git push origin --delete branch_name
git push origin --delete branch_name
git branch
git branch
git checkout Branch_Name
git fetch origin
git merge origin
git branch
git checkout Branch_Name
git pull origin master
git branch
git checkout main
git fetch
git merge
git branch
git checkout Branch_Name
git pull
git pull origin master
✍️ Blog Link Step By Step: (👉Click Here)
🎥 Video Tutorial : (👉Click Here)
git checkout -b newbranch
git branch
git status
git add .
git commit -m "commit name"
git push origin newbranch
🍀 Setup NPM & NodeJs (👉Click Here)
Basic Way | Advanced Way |
---|---|
git commit -m <message> |
git commit -m <title> -m <description> |
👉 Capitalize the first word and do not use in punctuation end
👉 Example :
❌❌ adding menu bar.
✅✅ Adding menu bar
👉 Use imperative mood in the subject line
👉 Example :
❌❌ dark mode toggle state
✅✅ Add fix for dark mode toggle state
👉 Use consistent set of words to describe your changes
👉 Example :
✅✅ Bugfix , Update , Refactor
👉 Be direct, try to eliminate filler words and phrases like (like : though, maybe, I think, kind of)
👉 Example :
❌❌ I added dark mode and maybe it has some issue
✅✅ Add fix for dark mode toggle state
👉 It creates a beautiful expression of the commit
👉 Example :
❌❌ Add fix for dark mode toggle state
✅✅ ➕ Add fix for dark mode toggle state
⚠️ NT : Since emojis use special ASCII codes (not commonly used and supported in the text-based interfaces like CLIs) and Unicode systems and most command-line interfaces need a third-party package or font to handle them, this convention might not look good to everyone. They might face some issues in terms of reading histories and checking the commit messages. (Like the emoji character in the message title might be rendered as its actual ASCII code or unknown question marks)
👉 Use a conventional Keyword first : Then explain the commit in detail
👉 Convetional Keywords like
- feat , fix , chore
- update , refactor , remove
- docs , style
- test , build , revert
👉 Example :
❌❌ fixed bug on landing page
✅✅ ➕ Fix: fix bug on landing page
👉 Format : git commit -m "feat: message"
✍️ When you add an existing new feature, use ‘feat’ commit type. It helps team members identify and track significant changes easily.
👉 Format : git commit -m "fix: message"
✍️ Addressing a bug ? Utlize ‘fix’ commit type to highlight that the commit resolves an issue or a problem in the repository code base
👉 Format : git commit -m "chore: message"
✍️ For non-feature/non-fix updates like updating dependencies or performing routine tasks, use ‘chore’ commit type
👉 Format : git commit -m "refactor: message"
✍️ When you improve the structure or readability of the code without adding features or fixing bugs, use ‘refactor’ commit type
👉 Format : git commit -m "docs: message"
✍️ Updating project documentation? Whether it’s the README or other relevant files , ‘docs’ commit type keeps the documentation up to date
👉 Format : git commit -m "style: message"
✍️ For changes that don’t affect code behavior but enhance code style or formatting , use ‘style’ commit type
👉 Format : git commit -m "test: message"
✍️ When you add or modify tests to ensure code quality and reliability , use ‘test’ commit type to keep track testing effort
👉 Format : git commit -m "perf: message"
✍️ Did you optimize the code to boost performance? Use ‘perf’ commit type
👉 Format : git commit -m "perf: message"
✍️ Changes related to continuous integration, such as configuring pipelines or adjusting build process, should use the ‘ci’ commit type
👉 Format : git commit -m "build: message"
✍️ For changes impacting the build system or external dependencies such as package updates or build script modification , use ‘build’ commit type
👉 Format : git commit -m "revert: message"
✍️ Mistakes happen! if you need to undo a previous commit , use ‘revert commit type to roll back changes and restore the previous states
git config --global http.proxy
git config --global --unset https.proxy
git add .
git commit -m "Commit Message Type"
git commit --amend --date="2023-07-07 20:12:20"
git push origin master
There are various types of files we might want the git to ignore before committing, for example, the files that are to do with our user settings or any utility setting, private files like passwords and API keys. These files are not of any use to anyone else and we do not want to clutter our git. We can do this with the help of “.gitignore”
.gitignore is an auto-generated file inside the project folder that ignores/prevents files to get committed to the local and remote repositories.
git init
git add .
git commit - m "Testing Git Ignore"
git push
Blank Line: A blank line doesn’t refer to any file name, so we can use it to separate two file names for the ease of reading .
#: A line beginning with the # symbol refers to a comment .However if # is used as a pattern then use backslash (“\”) before the # symbol so that it is not misunderstood as a comment.
/: It is used as a directory separator i.e to include directories, for example webdev/ .
*.extension_name: For example _.txt and _.log can be used to match ALL the files that have .txt and .log as their extension respectively.
**/any_name: It is used to match any file or directory with the name any_name.
any_name/**: It is used to match anything that is inside the directory of the name - any_name. for example webdev/** matches all the files inside webdev directory.
# Compiled class file // Comment
*.class // Ignore Extension Type
# Log file
*.log
# Mobile Tools for Java (J2ME)
.mtj.tmp/ // Extension Directory Type
# Package Files
*.jar
➡️ Find the project's repository on GitHub
➡️ Then "fork" it by clicking the Fork button in the upper right corner
This creates a copy of the project repository in your GitHub account.
In the upper left corner, you will see that you are now looking at a repository in your account:
➡️ While still in your repository, click the green Clone or download button
and then copy the HTTPS URL
Using Git on your local machine, clone your fork using the URL you just copied:
" git clone URL_OF_FORK "
Clone the repository you want to contribute from in your machine ( Copy the repository Link and Write the following code in Git Bash )
git clone https://github.com/Sumonta056/GitHub-Tutorial.git
Since the clone was downloaded into a subdirectory of your working directory, you can navigate to it using:
cd GitHub-Tutorial
You are going to be synchronizing your local repository with both the project repository (on GitHub) and your fork (also on GitHub). The URLs that point to these repositories are called “remotes”. More specifically, the project repository is called the “upstream” remote, and your fork is called the “origin” remote.
When you cloned your fork, that should have automatically set your fork as the “origin” remote. Use git remote -v to show your current remotes
git remote -v
You should see the URL of your fork (which you copied in step 2) next to the word “origin”.
If you don’t see an “origin” remote, you can add it using: git remote add origin URL_OF_FORK.
git remote add origin https://github.com/Sumonta056/GitHub-Tutorial.git
Add the project repository as the “upstream” remote using: git remote add upstream URL_OF_PROJECT.
git remote add upstream https://github.com/scikit-learn/scikit-learn.git
Before you start making any changes to your local files, it’s a good practice to first synchronize your local repository with the project repository. Use git pull upstream master to “pull” any changes from the “master” branch of the “upstream” into your local repository. (If the project repository uses “main” instead of “master” for its default branch, then you would use git pull upstream main instead.)
git pull upstream master
git pull upstream main
If you forked and cloned the project repository just a few minutes ago, it’s very unlikely there will be any changes, in which case Git will report that your local repository is “already up to date”. But if there are any changes, they will automatically be merged into your local repository.
Rather than making changes to the project’s “master” branch, it’s a good practice to instead create your own branch. This creates an environment for your work that is isolated from the master branch.
git branch branch-name
git checkout branch-name
Use git branch to show your local branches. You should see your new branch as well as “master”, and your new branch should have an asterisk next to it to indicate that it’s “checked out” (meaning that you’re working in it).
git branch
Use a text editor or IDE to make the changes you planned to the files in your local repository. Because you checked out a branch in the previous step, any edits you make will only affect that branch.
After you make a set of changes, use git add . to stage your changes and git commit -m “DESCRIPTION OF CHANGES” to commit them. Make changes. For example, I am creating a two file “file1.md” and “file2.md”
git add file1.md file2.md
git commit -m "my snapshot"
If you are making multiple sets of changes, it’s a good practice to make a commit after each set.
When you are done making all of your changes, upload these changes to your fork using git push origin BRANCH_NAME. This “pushes” your changes to the “BRANCH_NAME” branch of the “origin” (which is your fork on GitHub).
Use any of the following code of pushing to repository
git push origin branch-name
git push --set-upstream origin my-branch
Return to your fork on GitHub, and refresh the page. You may see a highlighted area that displays your recently pushed branch:
Click the green Compare & pull request button to begin the pull request.
(Alternatively, if you don’t see this highlighted area, you can switch to your branch using the Branch button and then click the New pull request button.)
Congratulations on making your first open source contribution! 🎉
If you’re ready to start making code contributions (beyond just fixing typos), here are a few tips:
A merge conflict is an event that takes place when Git is unable to automatically resolve differences in code between two commits. Git can merge the changes automatically only if the commits are on different lines or branches.
The following is an example of how a Git merge conflict works:
Let’s assume there are two developers: Developer A and Developer B. Both of them pull the same code file from the remote repository and try to make various amendments in that file. After making the changes, Developer A pushes the file back to the remote repository from his local repository. Now, when Developer B tries to push that file after making the changes from his end, he is unable to do so, as the file has already been changed in the remote repository.
To prevent such conflicts, developers work in separate isolated branches. The Git merge command combines separate branches and resolves any conflicting edits.
👉 Format : git log --merge
✍️ This command helps to produce the list of commits that are causing the conflict.
👉 Format : git diff
✍️ This command helps to identify the differences between the states repositories or file
👉 Format : git checkout
✍️ This command is used to undo the changes made to the file, or for changing branches..
👉 Format : git reset --mixed
✍️ This command is used to undo changes to the working directory and staging area
👉 Format : git reset --mixed
✍️ This command helps in exiting the merge process and returning back to the state before the merging began.
👉 Format : git reset
✍️ This command is used at the time of merge conflict to reset the conflicted files to their original state.
👉 Format : git status
✍️ This command displays the current state of the working directory and the repository.
✍️ It shows which files are modified, untracked, or staged for commit.
👉 Format : cd documentss
✍️ 'cd' is used to change the current working directory in the command line..
👉 Format : cat file.txt
✍️ 'cat' stands for "concatenate" and is used to display the contents of a file..
👉 Format : vi example.txt
✍️ 'vi' is a text editor available on Unix-like operating systems.
✍️ It allows you to create and edit files from the command line.
👉 Format : git rebase origin master
✍️ This command is used to reapply commits on top of another branch
(usually master) to incorporate changes and keep a linear commit history..
👉 Format : git rebase --abort
✍️ This command aborts an ongoing rebase operation,
reverting the repository back to its original state before the rebase.
👉 Format : git merge branch-name
✍️ This command merges changes from one branch into another.
👉 Format : git mergetool
✍️ This command launches a merge resolution tool
to help resolve conflicts during a merge or rebase.
👉 Format : git rebase --continue
✍️ This command continues a rebase operation after
resolving conflicts in the conflicted files.
git commit --amend
✍️ New Window will open where in top you see the last commit message
✍️ Write the following commands
Press ESC
Press I
Press ESC
Press SHIFT + Z + Z
git push -f
git rebase -i HEAD~5
[Here 5 = How Many last commit you want to see]
✍️ New Window will open where in top you see the all last commit message upto 5
✍️ Choose the desire commit Then
Press ESC
Press I
Press ESC
Press SHIFT + Z + Z
git commit --amend
Press I
Press ESC
Press SHIFT + Z + Z
git push -f
git push origin HEAD:main
git branch -M main
git rebase --continue
git push -f
Git reset will undo changes up to the state of the specified commit ID. For example, reverting to the second commit ID will undo changes and leave the state of the file as the state of the second commit. Ggit revert will undo changes up to the state before the specified commit ID. For example, reverting to the second commit ID will undo changes and leave the state of the file as the state of the commit that comes before the second commit – the first commit.
The explanations above may seem confusing. The best way to understand it is to try it out yourself.
You should use git reset when working on a local repository with changes yet to be pushed remotely. This is because running this command after pulling changes from the remote repo will alter the commit history of the project, leading to merge conflicts for everyone working on the project.
Git reset is a good option when you realize that the changes being made to a particular local branch should be somewhere else. You can reset and move to the desired branch without losing your file changes.
Git revert is a good option for reverting changes pushed to a remote repository. Since this command creates a new commit, you can safely get rid of your mistakes without rearranging the commit history for everyone else.
git log --oneline
We have selected the “Files added” commit, whose hash value is “9bd11a3”
git reset --hard 9bd11a3
git add .
git commit -m "Your Message"
git push origin main
git log --oneline
We have selected the “Files added” commit, whose hash value is “9bd11a3”
git revert 9bd11a3
Type "Esc"
Type "SHIFT + Z + Z"
Type ":wq"
git add README.md
Learn Markdown Langaue
Readme Design Tools Advance
GitHub Profile Readme Design Tools and Useful Website
Automation Update Using GitHub Action and Workflows
Create a new repo at GitHub.
Navigate to your local Git repository in your terminal.
cd /path/to/your/repoin
git remote rename origin upstream
git remote add origin URL_TO_NEW_GITHUB_REPO
git push origin main