Git Full Speed Ahead Part 3: Git Remote Repositories: Push, Pull, and Collaborate Easily

Table of content

• What is a Git Branch?
• Basic Git Branch Commands
• Creating a New Branch
• Switching Branches
• Merging a Branch into the Main Branch
• Deleting a Branch
• Understanding git push in Depth
• Creating a PAT (Personal Access Token)
• Working with Remote Repositories in Git
• Step 1: Configuring a remote
• Step 2: Pulling and cloning repositories
• Step 3: Pushing changes to remote
• Removing or updating a remote config
• Renaming a Branch
• GIT FETCH

🪴 What is a Git Branch?

In version control systems like Git, a branch is a separate line of development. It allows you to work on new features or bug fixes independently, without affecting the main codebase (usually main or master).

Think of Git as a map of your project, where each branch is a different route you can take. For example:

• main (or master) → The stable code, ready for production
• feature/login → Developing a login system
• bugfix/header → Fixing a header display issue

Branches let you experiment safely, collaborate with teammates, and keep the codebase organized. They’re a core concept in Git that make development smoother and more predictable.

✅ Benefits of Git Branches

1. Parallel Development: Multiple developers can work on different features at the same time.
2. Risk Isolation: Changes are made on separate branches, so the main branch remains safe from accidental issues.
3. Easy Cleanup: If a branch introduces problems, it can simply be deleted without affecting the main codebase.

Understanding Git Branches in One Picture 🧠

When we start a new project with git init and follow it with git add and git commit, we get an initial branch called main (or master, depending on the Git version).

In this diagram, each circle represents a commit we’ve made, and the lines show the path of the main branch.

📌 Two key points in the diagram:

Before the commit named main 1.1, a branch called bugfix was created to fix a bug. It was later merged back into main at main 4.1.

After main 1.1, another branch called feature was created to work on new developments. This branch hasn’t been merged back yet (it’s still separate).

This is one of Git’s superpowers: it allows us to work on multiple things simultaneously without mixing them together. You can develop new features, fix bugs, or even experiment on a temporary branch, all safely 🤓.

“Think of it like taking a side road: you go fix something, and then come back to the main road — Git makes this simple and safe.”

🧬 Git Branch Inheritance: Step by Step

What Happens:
Branch main
This is the starting point. All commits, the staging area, and the working directory contain only the data from main.

Branch feature-1
When we create this branch from main, it gets a “snapshot” of the latest state of main at that moment.
This means commits, the staging area, and the working directory include everything from main plus any changes made in feature-1.

Branch feature-2
This branch is created from feature-1, so it inherits everything from main + feature-1, and adds only the changes specific to feature-2.

How Are the Different Parts of Git Separated?

Git Component	Meaning in This Context
commit	A recorded snapshot saved in Git’s database (git commit).
staging area	Changes prepared for the next commit (git add places them here).
working directory	The actual files you see in your project folder right now (may not be committed or staged yet).
Ref (HEAD/heads)	A pointer to the latest position of each branch.

So, when feature-2 is created from feature-1, it’s like Git saying:
“Okay, I’ll start a new branch and copy over the latest state of feature-1 — including commits, the staging area, and the working directory — so you can continue working from there.”

🔁 Common Misconception:

“For example, if the main branch gets a new commit, it will automatically affect all branches created from it.”

✅ The Truth:

A new commit on one branch does not affect any other branch.

(This applies to main, feature, or any branch.)

Changes only propagate if you explicitly merge or rebase onto another branch.

🧪 Visual Comparison:

Creating a branch is like copying a friend’s notebook and writing in your own copy.
If your friend writes 10 more pages, your notebook doesn’t change — unless you decide to copy those pages again.

---

💻 Basic Git Branch Commands

Listing Branches
This command shows all the Git branches you have created.

git branch

git branch lists all branches and marks the current branch with an asterisk (*).

✏️ Creating a New Branch

This command is used to create a new branch.

git branch <branch-name>

Use this command to create a new branch with the specified name.

❌ Branch Naming Rules (Must Avoid or Strongly Discouraged)

1. Do not use names that conflict with Git references
Examples: HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD, index

2. Do not use spaces
Example: feature new login → ✅ feature-new-login or feature/new-login

3. Do not start or end with /
Example : /feature/login, feature/ → ✅ feature/login

4. Do not use .. (two consecutive dots)
Example: feature..bugfix

5. Do not use @{}
Example: fix@{bug}

6. Avoid certain special characters
Example: ~, ^, :, ?, [, \

7. Do not name a branch the same as a tag

♻️ Switching Branches

git switch <branch-name>

Use this when you want to switch and start working on a different branch.

TIP

You can combine creating a new branch and switching to it in a single command:

git switch -c <branch-name>

⚡ Merging a Branch into the Main Branch

Git merge is a fundamental command in Git that allows you to combine the development histories of two or more branches into a single branch. It is a key part of collaborative workflows, as it enables developers to integrate new features and bug fixes from a feature branch into the main branch of a project without losing any work.

git merge <branch-name>

In the example above, I added an option file in the ABC branch. When merging the ABC branch into main, Git shows the changes, and using git log reveals that the commit history from the ABC branch has also been included.

📛 Deleting a Branch

You can remove a branch that is no longer needed using the following command.

git branch -d <branch-name>

⚠️ Caution

git branch -d and git branch -D are not the same.

✅ git branch -d – Safe delete

• Deletes the branch only if it has been fully merged into your current branch (e.g., main).
• Prevents you from losing any unmerged work.
• Git will show an error if the branch hasn’t been merged yet.

⚠️ git branch -D – Force delete

• Forces deletion even if the branch hasn’t been merged.
• Can accidentally delete work that hasn’t been merged yet.
• No safety checks are performed—you might lose unmerged changes.
• Equivalent to git branch --delete --force.

---

🚀 Understanding git push in Depth

Have you ever wondered... after finishing work on your local machine, how do you make your code appear on GitHub? The answer is git push!

In this article, we’ll dive into what the git push command is, how it works, and the key things you should know to use Git with more confidence 💪

🔼 What is git push?

git push is the command used to push your code from your local machine to a remote repository (such as GitHub, GitLab, or Bitbucket).

💡 Benefits of git push

1. ✅ Backing Up Code

• Keeps your code safe even if your computer is damaged.
• A copy of your code lives on GitHub or another remote.

2. 👥 Team Collaboration

• Team members can pull (git pull) the latest code from the remote to continue working.
• Prevents duplicate or conflicting code.

3. 📜 Change History

• Every push records the current state of your project.
• Makes it easy to roll back or restore a previous version.

4. 🌍 Sharing Code

• Share your code with others for viewing or review.
• Handy for submitting work via a GitHub link.

5. 🚀 Automatic Deployment

• Some systems (like Vercel, Netlify, or CI/CD pipelines) automatically deploy your project whenever you push.

🔁 Quick Recap: Local vs Remote

git commit → Saves your changes locally on your machine
git push → Sends those changes to the server

Explaining the Diagram

1. Starting Point: Synchronized

• The Local Repository (on your computer) and the Remote Repository (on the server) contain the same code, because you’ve already pushed.

2. While Working: Unsynchronized

• You create Commit 2 locally, then continue working and create Commit 3.
• At this point, the Local repository is two commits ahead of the Remote, but nothing has been pushed yet.

3. Ending Point: Synchronized Again

• When you’re ready, you can push once to send both Commit 2 and Commit 3 to the Remote.
• Now the Local and Remote repositories are back in sync.

A single push can send all pending commits at once—there’s no need to push after every commit.

---

📌 Creating a PAT (Personal Access Token)

1. You need to have a repository on GitHub. If you don’t have one yet, see Part 1.
2. You’ll need to prepare a PAT by following these steps:
3. Go to GitHub, click on your profile in the top-right corner, and select Settings.

4. Go to the Developer settings section on the left-hand side.

5. Click on Personal access tokens, where you’ll see two options: fine-grained tokens and classic.

📭 Note

• Classic PATs → Provide very broad access across personal and organizational repositories. If the key is leaked, the risk is high.
• Fine-grained Tokens → Allow more precise control, such as limiting access to specific repositories or granting permissions by category (e.g., read/write issues, code). This reduces potential damage if the key is leaked and is better suited for high-security needs.

In my example, I chose Fine-grained tokens and clicked Generate new token.

7. Enter the details
* Token name – Give your token a recognizable name
* Description – Add optional details about the token’s purpose
* Owner – Select the account that will own the token
* Expiration date – Set when the token should expire
* Repository access – Choose which repositories the token can access

• Public repositories → The token can only access public repos. Ideal if you just need to fetch open-source code or run automation without touching your private repos.
• All repositories → The token can access all repos you have permission for, both public and private. This gives full access but carries higher risk if the token is exposed.
• Only select repositories → The token can only access specific repos you choose when creating it. Best for limiting scope to a single project or targeted automation.

8. Set the necessary permissions – For example, set Contents to Read and Write.

8.1 Make sure the permissions match the task you need.
8.2 Incorrect settings may cause the token not to work or reduce security.
8.3 Once configured, click Generate Token.

9. Copy the PAT and store it somewhere safe.

---

📡 Working with Remote Repositories in Git

When working with Git, you usually start with a local repository on your machine. But to collaborate with others or back up your code, you’ll need to connect it to a remote repository (such as GitHub, GitLab, or Bitbucket).

🛠️ Step 1: Configuring a remote

1. After making your commits and preparing to push to a repository for the first time, use the following command:

git branch -M main

2. Next, check whether the repository URL has been configured using this command:

้git remote -v 

If the command returns the repository name, you can skip steps 3–4. If it returns nothing or prompts for a new input, follow steps 3–4.

3. Go to the GitHub website, navigate to Profile > Your repositories, and select the repository you want.

4. Copy the repository's URL.

4.1 If you’re working in a team or joining an existing project where the repository already has commits, the process to copy the URL is slightly different: go to Code and copy the repository URL from there.

Once you have the repository URL, use the following command:

git remote add origin <url repository>

Example

---

🔄 Step 2: Pulling and cloning repositories

🌀 Git Clone

The git clone command is used to copy a project from a remote repository to your local machine.
It brings over everything — branches, commits, files, and folders — so you can start working with the project locally.

This command is typically used in the following cases:

• When you’re joining a development team that already has a remote repository.
• When you want to fork a repository and work on your own copy.
• When you need to clone a template repository to start a new project.

👉 In short, git clone is usually the first command you run when getting a project from a remote server.
After cloning, you’ll use other commands like git pull to keep your local copy up to date.

git clone command

    git clone <repository-url>

📜 Note

When you use git clone, there’s no need to run git init — the repository is already initialized for you.

📟 Git PULL

git pull is the command used to update your local Git repository with the latest changes from the remote repository.
It essentially combines two commands in one: git fetch + git merge.

1. Make sure you are on the branch you want to pull. For example, if you want to pull updates from the main branch, switch to main first.
2. Run the git pull command.

git pull

This table shows what happens when you run git pull, depending on whether your local branch is behind or up-to-date with the remote. It’s a quick reference for expected results and potential conflicts.

Local vs Remote State	Merge Direction in git pull	What Happens	Common Outcome	Notes
Local is older than remote	Remote → Local	Remote commits are merged (or fast-forwarded) into your local branch.	Local branch moves forward to match remote.	No conflicts unless overlapping changes exist.
Local is equal to remote	No merge	Nothing to merge — histories are identical.	“Already up to date.”	Working tree stays the same.
Local is newer than remote	Remote → Local	Git fetches remote, but since it’s behind, merge usually does nothing.	Local branch unchanged; remote stays behind until git push.	Merge step may be skipped entirely if there are no remote changes.
Local and remote have diverged	Remote → Local	Remote commits and local commits are merged together.	Merge commit created (or rebase if using -rebase).	Can cause merge conflicts; both histories are preserved.

---

🚀 Step 3: Pushing changes to remote

🌈 GIT PUSH

The push command sends your local changes to the remote repository.

git push -u origin <branch>

Example

git push -u origin main

This command means: send all changes from the local main branch to the remote repository named origin.

1. When using git push, Git will prompt you to enter a password or token via a sign-in window (in this example, a token was used).

1.1 Select Token.
1.2 Enter your PAT in the input field (refer to the “Creating a PAT” section).

2. Once the token is entered correctly, the local data will be successfully pushed to the remote repository.

✳️ Pushing All Branches

Previously, we pushed branches one at a time. If you have multiple branches, that means repeating the push process for each branch separately.

Instead, if you want to push all branches at once in a single command, you can use:

git push --all

---

🔦 Commands for managing your remote and local branches:

🗑️ Removing or updating a remote config

If you want to remove or update the configuration of a remote connection, you can do so with the following command:

git remote rm origin

The command git remote rm origin is used to remove the connection between your local Git repository and the remote repository named origin.
This removal does not delete the repository on GitHub; it only disconnects the link from your local machine. All files and history on GitHub remain intact.

✒️ Renaming a Branch

If you mistyped a branch name or want to change it, use this command.

git branch -m <old-branch-name> <new-branch-name>

Example

🎯 GIT FETCH

Understanding git fetch

When you run git fetch, Git checks the remote repository (like GitHub) for new commits, branches, and tags. It downloads these new items and stores them in your local repository as remote-tracking branches (e.g., origin/main). Your local working files and branches remain untouched.

git fetch

From this example, let's say someone else has updated the main branch on the remote repository.

Initially, if you run git status, it might report that your local branch is "up to date" because it's only checking its internal data, which doesn't know about the new remote changes yet.

When you run git fetch, Git downloads those new changes. Although git fetch itself often doesn't produce a clear output, your local repository now has the new data.

To see the result of the git fetch, you can then run git status again. It will now report that your local main branch is behind the origin/main branch. This is the explicit "report" you were looking for.

If you were to make changes and push to main without updating first, your changes would be rejected by the remote repository. This is a safety feature to prevent you from accidentally overwriting the updates from your teammates. To fix this, you would need to use git pull to first merge the remote changes into your local branch before pushing again.

✒️ Note
If you’ve already run git fetch before, running it again may not show any new downloads — but that doesn’t necessarily mean your local repository is fully up to date with the remote. It’s recommended to run git status to verify the current state.

💡 Best Practice with git fetch

• Run git fetch before git status to check if you’re behind the remote.
• Always run git fetch before git push to avoid conflicts.

Remember: Running git fetch twice in a row might not show new output — it simply means nothing has changed remotely since the last fetch.

Command	What it does	When to use
git fetch	Downloads new data from remote but doesn’t change local files	Safe check for updates
git pull	Downloads and merges remote changes into local branch	When you’re ready to update your branch

---

🏁 Wrapping Up

We’ve covered the core Git commands for working with remotes — from cloning and pulling to pushing and managing configs.

Keep practicing these commands, and soon collaborating with Git will feel second nature. 🚀