sudo pacman -S git

After this, you can also verify the git installation using the following command:

git --version

This command will show your installed version of git, this shows that git has been properly installed in your system and you are ready to move on with it. Now that we are done with installation of git, let’s start with orientation of GitHub as well to learn these tools in parallel and get the best out of them.

• Local (On Your System)
• Remote (On Your GitHub)

git config --list

This will show the current configured username and email that git is handling. After this one-time setup is done, let’s create our first Local Repo using git.

mkdir Demo

Then we need to enter this folder, you can do this by running the command:

cd Demo

git init
git branch -M main

What this does is that it turns the current folder into a local repo and the second command renames your current branch to “main”, by default it’s named as master. We will learn what a branch is when we get there, for now just let it slide and don’t sweat it. Git starts monitoring any files in this folder (Local Repo) from now on. Hence, git is active and in action now.

git remote add origin https://github.com/coder-Retro/Demo.git

This command connects our local repo to the remote repo and allows the communication between both of them from now on, we can tranfer data from local to remote and vice versa now. Congratulations on making your first repository. Next up, we will learn how to add contents to our repos.

#include<iostream>
int main(){
    std::cout << "This is my Demo Project";
    return 0;
}

Now save this file in your local repo. Let’s see if git is tracking our file or not. For this, run the command:

git status

You will see the following on your terminal:

On branch main
No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .vscode/
        test.cpp

nothing added to commit but untracked files present
(use "git add" to track)

This means that git is not tracking your test.cpp yet, in order to make git track it, run the following command:

git add .

This command tells git to track all the files in the current folder. Now run the status command again and you will see this now:

On branch main
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   test.cpp

This means that git has started tracking your test.cpp.

git commit -m "Any Message"
git push origin main

The first command creates a snapshot of your current added file. Then the second command sends that snap shot to the main branch in your remote repo.

1. Go to Developer settings
2. Go to Personal access tokens
3. Go to Tokens (classic)
4. Click "Generate new token (classic)
5. Give it a name (e.g., "GitCLI"), and check the repo box.
6. Click "Generate token" and copy it immediately
7. Note: You won't be able to see it again!
8. Enter this token when your terminal asks for your "Password."

git push origin main

Now if you go back to you GitHub and open the Demo repo and refresh the page. You will see that your test.cpp has appeared in remote repo. You will also see the text “Any Message” in front of it, this is called a commit message and people use it to determine what change they performed in the pushed file.

.vscode/

Then save and close it. Now, because we ran git add . in our previous step, Git has already indexed and started tracking our .vscode/ folder! Simply creating a .gitignore file won’t stop git from tracking files it has already noticed. We need to clear it from git’s active tracking memory first. Run this specific sequence of commands to untrack the folder and push your new rules to GitHub:

git rm -r --cached .vscode
git add .gitignore
git commit -m "Add: .vscode to gitignore"
git push origin main

The first command tells Git to safely drop .vscode/ from its tracking registry without deleting the actual files from your hard drive. The subsequent commands log your .gitignore rules into your history and upload them. If you open your remote repo on GitHub, you will notice that the .vscode/ folder has vanished from the cloud while remaining fully intact on your machine. From this point forward, Git will silently ignore it on every single push.

git switch main
git pull origin main

The first command makes sure that we are on our main branch. If you are already on the main branch, you can skip this command. Then, the second command fetches the files from remote repo onto our local repo to make sure that our local repo has the latest updates before we start working on anything. First we need a name for our feature branch, for now we will name it “feature-branch”. Now let’s make our feature branch by running this command:

git switch -c feature-branch

This command not only makes a new feature branch but also takes us to it. You can also check which branches your have in your repo and your currently active branch by running this command:

git branch

You will see the list of all current branches on your repo and your currently active branch will be marked with a “*” symbol. My Demo Repo’s branch list looks like this right now:

* feature-branch
  main

The “*” symbol shows that I am currently working on the feature branch, you can switch between branches using any of the following two commands:

git checkout targetBranchName
git switch targetBranchName

Now anything we do on this feature branch will not modify the main branch itself. Let’s verify this by editing the test.cpp on this feature branch. Open your test.cpp and add a line in the main function after the last cout:

#include<iostream>
int main(){
    std::cout << "This is my Demo Project";
    std::cout << "\nThis is a Feature";
    return 0;
}

Save your file and then add, commit and push it to your feature branch using the previously learnt commands:

git add test.cpp
git commit -m "feat: Added Feature"
git push origin feature-branch

Now go to your GitHub and open your test.cpp, your will see something like:

• Through Command Line using git
• Creating Pull Request using GitHub

git switch main
git merge feature-branch
git push origin main

The first command switches control to your main branch in local repo, the second command merges the updated files from your feature branch into your main branch in local repo, then the third command updates your remote repo’s main branch with these modifications as well. You can verify these change by going onto your GitHub and checking the file in main branch to see updates.

git switch main
git pull origin main
git branch -d feature-branch
git push origin -d feature-branch

The first command will switch us to main because in order to delete a branch, we need to move to another branch as git does not allow you to delete your currently active branch. So first command will switch us to main. Then second command will update your local’s main to remote’s main (updated after merge). Then third command will delete our feature branch in our local repo. And finally fourth command will delete our feature branch from our remote repo on GitHub. You can verify the deletion of your local repo’s feature branch by running:

git branch

You will see that your feature branch is deleted in your local repo. Similarly you can verify the deletion of your remote feature branch by going to the branch switch menu of your repo on GitHub:

git clone TargetRepoURL

You can find the repo’s URL on GitHub in the blue/green “Code Menu” when you open that repo, for example let’s say we want to clone the Demo Repo we have been working on, then we would copy the given URL from the Repo on GitHub and replace the “TargetRepoURL” with it:

cd TargetRepoName

However, do know that the repo might be owned by someone else and they might not have given you the rights to push anything to the remote repo like a collaborator could do. So you can play around with the local repo, but not the remote version of this cloned repo. Other than that, making branches and merging into main in your local repo is all the same as studied before. So now you know how to make a repo from scratch as well as how to clone a built one. Now we can move onto the actual core concepts of git and GitHub, basically the version control part of it, that allows us to track the changes made to files in our project and also to load old checkpoints if needed.

git log

You will see the history of all the commits made to the project. My Demo Repo’s History looks like this right now:

commit 6998eaa85661853059f2bd76249662a63df64ce8
(HEAD -> main, origin/main, origin/HEAD)

Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:14:56 2026 +0500

    feat: Added Feature

commit a502c4a53ae37f001db0555b325fd3339f5db4bf
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:12:00 2026 +0500

    Add: .vscode to gitignore

commit 08964f140eee9b70a2f462094fd5947eb933d820
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:07:58 2026 +0500

    Any Message

If you want to start reading the commit history from the beginning of the project, then read the git log’s output from bottom to upwards. As you can see here that there are only three commits. Initial commit that we made through our main branch (Any Message), second commit where we added the gitignore and the third commit that we made through our feature branch (feat: Added Feature). Git log also tells us the time those commits were made along with the attached commit message. Now back to commit hash that we needed. You see the first line of each commit that says “commit” and then a long code after it, this long code is called the “Commit Hash”.

git switch main
git pull origin main

Then make a branch using the branch creation command and also switch to it. Let’s call this branch “remove-feature”:

git switch -c remove-feature

Now let’s run branch list command to make sure that our branch has been created and we are on the current branch:

git branch

It should look something like this:

* remove-feature
  main

Not let’s use our copied commit hash to revert the feature. For this, we need to run this command using our commit hash:

git revert --no-edit 6998eaa85661853059f2bd76249662a63df64ce8
git push origin remove-feature

Normally “git revert CommitHash” would have also worked, but sometime you will get an error regarding an editor called “vi” which might not be installed in your system, so to bypass that error we use the “no-edit” flag. Now the test.cpp in the remove-feature branch of our repo has been restored to its original form where the feature did not exist.

git switch main
git merge remove-feature
git push origin main

The first command will switch to main branch in local repo, the second command will merge the remove-feature of local repo into main branch of local repo and finally third command will update the code on remote repo’s main branch using the local repo’s main. Now let’s run git log to verify if our feature has been removed, you will see this:

commit 69a0bcc56c2173ab9e01ad92fcc1fe7f872adb3d
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 21:53:54 2026 +0500

    Revert "feat: Added Feature"
    
    This reverts commit 6998eaa85661853059f2bd76249662a63df64ce8.

commit 6998eaa85661853059f2bd76249662a63df64ce8
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:14:56 2026 +0500

    feat: Added Feature

commit a502c4a53ae37f001db0555b325fd3339f5db4bf
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:12:00 2026 +0500

    Add: .vscode to gitignore

commit 08964f140eee9b70a2f462094fd5947eb933d820
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:07:58 2026 +0500

    Any Message

As you can see that the latest commit says (Revert “feat: Added Feature”). You can also verify the feature removal by going to remote repo’s main:

git switch main
git pull origin main
git branch -d remove-feature
git push origin -d remove-feature

We already know what each of these commands do step by step. Congratulations on reverting your feature and restoring an older version of your project. This is one of the most important and amazing powers a developer can desire to have and that is exactly what git and GitHub deliver.

git switch main
git pull origin main
git switch -c feature-1

Then add the feature in your cpp using feature-1:

#include<iostream>
int main(){
    std::cout << "This is my Demo Project";
    std::cout << "\nThis is Feature 1";
    return 0;
}

Now save it, push it onto remote’s feature-1, then merge it into main and delete your feature-1 using:

git add test.cpp
git commit -m "Add: First Feature"
git push origin feature-1
git switch main
git merge feature-1
git push origin main
git branch -d feature-1
git push origin -d feature-1

By now, first feature has been added and feature-1 has been deleted from local and remote repo. Let’s add second feature by making feature-2 branch. Now since we are already on main and we know that our local’s main is updated with remote’s main, we will skip the “git switch main” and “git pull origin main” command. This is important to know which command does what and whether we need to run it or not:

git switch -c feature-2

Then add the second feature to your test.cpp like:

#include<iostream>
int main(){
    std::cout << "This is my Demo Project";
    std::cout << "\nThis is Feature 1";
    std::cout << "\nThis is Feature 2";
    return 0;
}

Now save test.cpp and repeat the same push and merge process for feature-2 as well:

git add test.cpp
git commit -m "Add: Second Feature"
git push origin feature-2
git switch main
git merge feature-2
git branch -d feature-2
git push origin -d feature-2

I have demonstrated the process two times for First and Second feature. Now add the Third Feature using feature-3 branch yourself. By the end, we will be on our main branch, all feature branches will be deleted and your test.cpp will look like this:

#include<iostream>
int main(){
    std::cout << "This is my Demo Project";
    std::cout << "\nThis is Feature 1";
    std::cout << "\nThis is Feature 2";
    std::cout << "\nThis is Feature 3";
    return 0;
}

So we added three features using 3 feature branches, now we need to learn how to remove everything added to our project ahead of a certain point. For now, let’s set this point as First Feature, which means that we will restore the project to the point where First Feature was added and anything added after that (Second Feature and Third Feature) will be removed. This is gonna be different than reverting, where reverting only undid a single commit, this will undo all the commits made after “Add: First Feature”, therefore the successive “Add: Second Feature” & “Add: Third Feature” commits will be undone. Let’s get down to it then.

git log

And we will be greeted with the history of commits of our project. Let’s look for the First Feature commit by searching through the commits using commit messages as a key. We are looking for a message that says “Add: First Feature”.

commit f3e2cd94b60ff4845dd3c80851a0f2ce6f6dd55f
(HEAD -> main, origin/main, origin/HEAD)
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Tue Jun 16 19:33:09 2026 +0500

    Add: Third Feature

commit a65d42aad6606b6c8aaae3d649ec45735f76ad4c
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Tue Jun 16 19:31:42 2026 +0500

    Add: Second Feature

commit fe312a3b08b8d16a3ac6a110a987d8a0ef307a0c
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Tue Jun 16 19:29:53 2026 +0500

    Add: First Feature

commit 69a0bcc56c2173ab9e01ad92fcc1fe7f872adb3d
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 21:53:54 2026 +0500

    Revert "feat: Added Feature"
    
    This reverts commit 6998eaa85661853059f2bd76249662a63df64ce8.

commit 6998eaa85661853059f2bd76249662a63df64ce8
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:14:56 2026 +0500

    feat: Added Feature

commit a502c4a53ae37f001db0555b325fd3339f5db4bf
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:12:00 2026 +0500

    Add: .vscode to gitignore

commit 08964f140eee9b70a2f462094fd5947eb933d820
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:07:58 2026 +0500

    Any Message

There it is, the commit message “Add: First Feature”. We will now copy its commit hash. Now after that, we need to start restoration to this commit hash.

git switch -c restore-branch

Now we have to restore our project for First Feature on this branch and then update main branch using this branch as reference. We can do this by first restoring the code on our restore-branch by using the following command with First Feature’s commit hash:

git reset --hard fe312a3b08b8d16a3ac6a110a987d8a0ef307a0c

What this will do? this will bring the test.cpp on your restore-branch to the exact state as when First Feature was added, “hard” flag is the thing responsible for restoring the physical file to this point, if you use “soft” flag then your file would be staged as First Feature commit, but the physical code would not have been lost in your code editor. Anyways, “hard” resets the file to that commit. You can verify this by the absence of Second and Third Features in your test.cpp file in your code editor. Now we just need to update main using this restore-branch. We can do that by running the following commands:

git push origin restore-branch --force
git switch main
git reset --hard restore-branch
git push origin main --force

The first command, you already know what it does but that “force” flag is new for you right? Well GitHub has a simple rule called the forward-movement principle. It only expects the user to move forward by keeping all the previous commits and adding new ones ahead of it. But here, we just restored the restore-branch to an older commit which removed the successive commits (Second Feature & Third Feature), now if we push to GitHub, this will be a backward-movement which GitHub sees as a mistake by the user. So by adding “force” flag, we are telling GitHub that “I know what I am doing so just listen to me and do it”. This allows GitHub to know that this backward-movement is intentional and not a mistake so GitHub breaks its forward-movement principle and allows us to go back to an old point and remove the successive commits ahead of that point. It will also remove the Second Feature and Third Feature’s commits from our project’s git log history as well. That’s what the “force” flag does. The second command then switches to main as you know already. The third command updated the local’s main to local’s restore branch. The fourth command then updates remote’s main using local’s main, and “force” flag is again used for the same reason here. Now let’s run git log to check the history:

commit fe312a3b08b8d16a3ac6a110a987d8a0ef307a0c
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Tue Jun 16 19:29:53 2026 +0500

    Add: First Feature

commit 69a0bcc56c2173ab9e01ad92fcc1fe7f872adb3d
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 21:53:54 2026 +0500

    Revert "feat: Added Feature"
    
    This reverts commit 6998eaa85661853059f2bd76249662a63df64ce8.

commit 6998eaa85661853059f2bd76249662a63df64ce8
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:14:56 2026 +0500

    feat: Added Feature

commit a502c4a53ae37f001db0555b325fd3339f5db4bf
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:12:00 2026 +0500

    Add: .vscode to gitignore

commit 08964f140eee9b70a2f462094fd5947eb933d820
Author: coder-Retro <hasnainqadri9c@gmail.com>
Date:   Sun Jun 14 18:07:58 2026 +0500

    Any Message

As you can see, latest commit is First Feature now and successive commits have been removed. You can also verify the change in you remote repo’s main.

git branch -d restore-branch
git push origin -d restore-branch

There we go, project restored to intended point and all cleaned up. Again, I would recommend to take a break here and practice what you have learnt in Basic and Advanced Version Control to get a good understanding of it. After that, we will move onto our last topic of this git & GitHub guide, which is “Merge Conflicts”.

git switch -c branch-1
git switch -c branch-2

Now if we run:

git branch

We will see something like this:

  branch-1
* branch-2
  main

Now let’s use branch-2 to edit a line in test.cpp. Open the test.cpp and make input a line like this:

#include<iostream>
int main(){
    std::cout << "This is my Demo Project";
    std::cout << "\nThis is Feature 1";
    std::cout << "\nThis is Branch-2's edit";
    return 0;
}

Now let’s update branch-2’s remote:

git add test.cpp
git commit -m "Add: Branch-2 edited line 5"
git push origin branch-2

Now let’s switch to branch-1 and edit the same line of test.cpp using branch-1:

git switch branch-1

After this, open test.cpp and add this line:

#include<iostream>
int main(){
    std::cout << "This is my Demo Project";
    std::cout << "\nThis is Feature 1";
    std::cout << "\nThis is Branch-1's edit";
    return 0;
}

Now save the file and push it to remote branch-1:

git add test.cpp
git commit -m "Add: Branch-1 edited line 5"
git push origin branch-1

Let’s perform the merge process by first opening a PR for each branch. Let’s revise the GitHub merge method while doing this. First we need to go to GitHub. Now we will see an option for both branch’s pull request on the main page right now, if they don’t appear then we can open PR’s by going to PR tab as well. Since we have already learnt how to do that before, you can use that method as well. I will directly click the following button for now:

git switch main
git pull origin main
git branch -d branch-1
git push origin -d branch-1
git branch -d branch-2
git push origin -d branch-2

Your can run git branch to verify the cleanup if you want. Congratulation! you have learnt what merge conflicts are, how they form and how you can fix them. We are officially done with our git and GitHub guide so let’s delete our Demo repo and mark an end to this journey. You can delete a Repo by going to the “Settings” tab on GitHub.

1. Git Setup
2. GitHub Setup
3. Repo Setup
4. Pushing Files to Repo
5. Cloning Repo
6. Branch Management
7. Branch Merging
8. Basic Version Control
9. Advanced Version Control
10. Merge Conflict