HEAD is a pointer that always refers to the current commit of the currently checked‑out branch. When we say reset HEAD, we are telling Git to move this pointer to a different commit and optionally adjust the staging area and working directory.
git merge preserves commit history by creating a merge commit, whereas git rebase rewrites commit history to create a clean, linear timeline, and should only be used on local branches.
Below are the complete step‑by‑step commands in simple plain text only, starting from a local folder and ending with pushing changes to the GitHub master branch.
Step 1: Go to your local project folder
cd your-folder-name
Step 2: Initialize a local git repository
git init
Step 3: Check repository status
git status
Step 4: Add all files to staging area
git add .
Step 5: Commit the files to local repository
git commit -m “Initial commit”
Step 6: Add the GitHub remote repository URL
git remote add origin https://github.com/username/repository-name.git
Step 7: Verify remote repository
git remote -v
Step 8: Set master branch explicitly (if needed)
git branch -M master
Step 9: Push local repository to GitHub master branch
git push -u origin master
If changes are already made later, use these steps:
Check modified files
git status
Add changes
git add .
Commit changes
git commit -m “Your commit message”
Push changes to GitHub master
git push origin master
Below are the simple plain‑text steps and commands, starting from cloning a repository to local, making changes, and pushing those changes back to the remote GitHub master repository.
Step 1: Clone the repository from GitHub to local
git clone https://github.com/username/repository-name.git
Step 2: Move into the cloned repository folder
cd repository-name
Step 3: Check the current branch
git branch
(or)
git branch –show-current
Step 4: Make required changes to the files locally
(Edit files using editor)
Step 5: Check what files are changed
git status
Step 6: Add modified files to staging area
git add .
(or for specific file)
git add filename
Step 7: Commit the changes to local repository
git commit -m “Meaningful commit message”
Step 8: Pull latest changes from remote master (to avoid conflicts)
git pull origin master
Step 9: Push your changes to remote master repository
git push origin master
If the branch is already tracking master, you can simply use
git push
Here is the explanation in simple plain text only, as you requested.
Internally, the git pull command performs two main operations.
First, git pull runs git fetch.
This step contacts the remote repository and downloads all new commits, updates, and references. It updates the remote‑tracking branches like origin/master or origin/main, but it does not change your local working files yet.
Second, after fetching, git pull integrates those fetched changes into your current local branch.
By default, this integration is done using git merge. If your local branch and the remote branch have not diverged, Git performs a fast‑forward merge. If they have diverged, Git creates a merge commit. In some cases, based on configuration, git pull may use rebase instead of merge.
If there are conflicts during this merge or rebase step, Git pauses and asks you to resolve the conflicts before completing the pull.
In simple terms, git pull internally does a git fetch followed by a git merge (or rebase), bringing remote changes into your current local branch.
Here is the explanation in simple plain text only, as requested.
Internally, the git push command sends your local committed changes to the remote repository.
First, Git checks which local commits are not present in the remote branch. It compares your local branch with the corresponding remote branch to identify new commits that need to be shared.
Next, Git transfers the required commit objects, file objects, and related metadata to the remote repository. Only the missing objects are sent, not the entire repository.
After the objects are successfully transferred, Git asks the remote repository to update its branch reference to point to the latest commit from your local branch. If the update is a fast‑forward (meaning no conflicting changes exist), the remote branch is updated.
If the remote branch has commits that your local branch does not have, Git blocks the push to prevent overwriting someone else’s work. In this case, you must pull and integrate those changes before pushing again, unless you force the push.
Once the remote branch reference is updated successfully, the push operation is completed and the changes become available to other collaborators.
In simple terms, git push uploads your local commits to the remote repository and updates the remote branch pointer if it is safe to do so.
A merge conflict in Git happens when Git is unable to automatically combine changes from two branches.
This usually occurs when two people modify the same file, and the same lines of code, in different ways. When Git tries to merge those branches, it cannot decide which change to keep, so it stops the merge and marks it as a conflict.
During a merge conflict, Git highlights the conflicting parts in the file and asks the developer to manually review and resolve them by choosing the correct changes or combining them.
Once the conflict is resolved, the file is saved, added again, and the merge is completed.
In simple terms, a merge conflict happens when Git cannot automatically merge changes and needs human intervention.
Here is the answer in simple plain text only, as you requested.
A merge conflict in Git is resolved by manually reviewing and fixing the conflicting changes.
First, when a merge conflict occurs, Git stops the merge process and marks the conflicted files. Git shows which files have conflicts.
Next, you open the conflicted file. Inside the file, Git clearly marks the conflicting sections using special markers. These markers show your changes, the incoming changes, and separate them.
Then, you manually decide how the final code should look. You can keep your changes, keep the other branch’s changes, or combine both in a correct way. After fixing the content, you remove all the conflict markers from the file.
Once the file is fixed, you save it and add it back to the staging area using git add. This tells Git that the conflict in that file is resolved.
After all conflicted files are resolved and added, you complete the merge by committing the changes.
In simple terms, resolving a merge conflict means manually fixing the conflicting code, adding the resolved files, and completing the merge.
Rebasing in Git is a way to integrate changes from one branch into another by rewriting commit history.
When you rebase a branch, Git takes the commits from your current branch, temporarily removes them, moves your branch to the latest commit of the target branch, and then reapplies your commits one by one on top of it. This makes it look like your work was started from the latest version of the target branch.
Unlike merge, rebasing does not create a merge commit. Instead, it creates new commits with new commit IDs, resulting in a clean and linear project history.
Rebasing is commonly used to keep a feature branch up to date with the main or master branch before merging, so that the final history looks simple and easy to understand.
However, rebasing should not be used on shared or public branches because it rewrites history and can cause issues for other team members.
In simple terms, rebasing moves your commits to the top of another branch to create a clean and linear history.
The main difference between git clone and git remote is their purpose and when they are used.
git clone is used to create a brand‑new local repository by copying an existing remote repository. It downloads all files, commit history, and branches, and automatically sets up a remote called origin pointing to the source repository.
git remote is used inside an already existing local repository. It does not download code by itself. It only adds or manages a reference (pointer) to a remote repository so that you can later fetch or push changes.
In simple terms, git clone is used when you are starting fresh and want a full copy of a repository, while git remote is used to connect an existing local repository to one or more remote repositories.
If you made changes but have NOT committed yet (local changes only)
To discard changes in a specific file and revert it to the last committed state
git checkout — filename
To discard changes in all files
git checkout — .
(Newer Git alternative)
git restore filename
git restore .
Use this when you edited files by mistake and want to undo them.
If you have staged changes but NOT committed yet
To unstage files but keep changes
git reset
To unstage a specific file
git reset filename
If you committed the change but have NOT pushed it to remote
To remove the last commit but keep changes in files
git reset HEAD~1
To completely remove the last commit and discard changes
git reset –hard HEAD~1
Use this only when the commit is local and not shared.
If you committed AND pushed the code (shared with others)
To safely reverse the code
git revert commit_id
This creates a new commit that undoes the changes from the given commit.
This is the safest way in shared branches like master or main.
If you want to fix the last commit (message or missed files)
To update the last commit
git add .
git commit –amend
This rewrites only the last commit.
If you want to go back to a specific old commit completely
To move back and discard everything after that commit
git reset –hard commit_id
Use carefully. This removes history.
Simple rule to remember
Uncommitted changes → checkout or restore
Committed but not pushed → reset
Committed and pushed → revert
Fix last commit → amend
Cherry‑pick in Git is used to pick a specific commit from one branch and apply it to another branch, without merging the entire branch.
It is mainly used when you need only one or a few specific changes (for example, a bug fix) from another branch.
Basic idea
Cherry‑pick copies the changes from a selected commit and creates a new commit on the current branch with those changes.
Step‑by‑step example with commands
Assume you have two branches:
feature branch (where the change exists)
master branch (where you want the change)
Step 1: Find the commit you want to copy
git log
(or)
git log feature
Note the commit hash you want to pick.
Step 2: Switch to the target branch
git checkout master
Step 3: Cherry‑pick the commit
git cherry-pick commit_hash
This applies the changes from that commit to master and creates a new commit.
Cherry‑pick multiple commits
To cherry‑pick multiple specific commits
git cherry-pick hash1 hash2
To cherry‑pick a range of commits
git cherry-pick start_commit^..end_commit
If a conflict occurs during cherry‑pick
Git pauses the process and shows conflicts.
After fixing the conflicts manually
git add .
Continue the cherry‑pick
git cherry-pick –continue
If you want to cancel the cherry‑pick
git cherry-pick –abort
Common real‑time use cases
Picking a bug fix from a feature branch to production
Applying a hotfix without merging unfinished features
Moving a commit made in the wrong branch to the correct branch
Important point to remember
Cherry‑pick creates a new commit ID, even though the changes are the same.
