DEV Community: Shane Dsouza

Prompting Techniques: How to Talk to AI (and Get What You Want)

Shane Dsouza — Mon, 14 Jul 2025 04:19:06 +0000

If you've ever used AI models like ChatGPT or Claude, you’ve probably noticed that the way you ask a question changes everything. It’s not just what you ask, it’s how you ask it. That’s where knowing how to prompt comes into play.

In the world of Large Language Models (LLMs), the concept of “Garbage In, Garbage Out” (GIGO) still holds true. If your input is unclear or confusing, the output will be too. But when you give good instructions, you usually get good results.

In this post, we’ll look at some common prompting techniques that can help you get better results when interacting with LLMs.

Prompting Techniques

Now that we understand the importance of clear instructions, let’s look at a few prompting techniques that can make a big difference. These simple methods help guide the model more effectively and improve the quality of the responses you get.

1. Zero-Shot Prompting

You ask the model to do something without giving any examples.

Example:

Generate a strong password using letters, numbers, and symbols.

Even though you didn’t show it how to make a password, the model understands and can create one for you.

2. Few-Shot Prompting

Here you give the model a few examples of what you want before asking it to do the task. This helps the model understand the style and how it should respond.

Prompt Setup:

You are an AI expert in Mathematics. You only solve math problems.  
If a user asks anything outside of math, politely let them know you can’t help with that.

Examples:
User: 8 + 4
Assistant: 8 + 4 = 12. By adding 8 with 4 we get 12.

User: 2 * 3
Assistant: 2 * 3 = 6. By multiplying 2 with 3, we get 6.

User: How to make tea?
Assistant: Sorry, I am just a Mathematics expert. I can only help with math problems.

3. Chain-of-Thought Prompting

Here, you guide the model to think step by step before responding, instead of jumping straight to the final answer.

Prompt Setup:

You are a helpful AI assistant who is specialized in resolving user queries.  
For the given user input, analyze the problem and break it down step by step.

The thinking process goes like this:
1. Analyse: Understand what the question is about  
2. Think: Start thinking through the steps  
3. Output: Give a direct answer  
4. Validate: Double check your logic  
5. Result: Present the final result with a brief explanation

Example:
User: What is 2 + 2
Output: { "step": "analyse", "content": "Alright! The user is asking a basic arithmetic question." }
Output: { "step": "think", "content": "To perform this addition, I must add 2 and 2." }
Output: { "step": "output", "content": "4" }
Output: { "step": "validate", "content": "Seems like 4 is the correct answer for 2 + 2." }
Output: { "step": "result", "content": "2 + 2 = 4, and this is calculated by adding both numbers." }

This style helps the model reason more clearly and avoid careless mistakes. It works well for logical or step-by-step problems.

4. Self-Consistency Prompting

With this technique, you ask the model the same question multiple times and compare the answers. The goal is to find the response that shows up most often or makes the most sense.

LLMs don’t always give the same answer every time you ask. They may follow different paths of thinking. Sometimes the first answer is right, sometimes it isn’t.

Self-consistency lets the model "think again," and you choose the answer that’s most consistent or reliable.

Example:

Question: Should I use dark mode or light mode on my phone?

You ask the model 3–5 times:

Try 1: Dark mode is easier on the eyes. → Answer: Dark mode
Try 2: Dark mode saves battery and looks better at night. → Answer: Dark mode
Try 3: Light mode is bright but can cause strain. Dark mode is better. → Answer: Dark mode

Since “Dark mode” is the most common answer, you go with that.

5. Persona-Based Prompting

Here you ask the model to take on a specific role or identity before answering any questions. This sets the tone, language, and point of view in the response.

Prompt Setup:

You are a local travel guide from Toronto. 
You speak in a welcoming, helpful tone and give practical tips for visitors.

Example:
User: I’m visiting Toronto for the first time. What should I do in one day?

Assistant: Welcome to Toronto. If you’ve only got one day, here’s how to make the most of it.
Start your day at the CN Tower for amazing city views. Then walk along the Harbourfront to enjoy the lake.
In the afternoon, explore the Distillery District for local shops and history.
End your day at Polson Pier, it’s the perfect spot to catch the sunset.

Final Thoughts

If there's one key takeaway from this post, it's this:

The way you talk to an AI makes all the difference.

It’s not magic. It’s communication.

And like any great conversation, it depends on tone, context, and clarity.

The better your prompt, the better the output.
Try using these techniques in your next chat with an AI and see the difference for yourself.

Want to go deeper? Try combining techniques, like persona-based + chain-of-thought, to get even better results.

Enjoyed this post?
Found it helpful? Feel free to leave a comment, share it with your team, or follow along for more.

🌐 shanedsouza.com

AI Buzzwords Decoded: What LLMs like ChatGPT Really Do

Shane Dsouza — Fri, 11 Jul 2025 01:57:31 +0000

Many of us use AI tools like ChatGPT or GitHub Copilot in our daily lives, but what actually powers them? If you've ever tried to read up on AI, you've probably run into terms like tokenization, embeddings, and transformers.

Sounds complicated? It doesn’t have to be.

Welcome to the world of AI, where tech buzzwords pop up faster than autocomplete suggestions. In this article, I’ll break down several AI jargon into simple concepts.

LLMs

LLM stands for Large Language Model, a type of AI trained to understand and generate human language. It takes in human text as input, processes it, and then produces a response that makes sense to us.

ChatGPT is one of the most popular LLMs, created by OpenAI and made accessible to the public.

GPT

GPT stands for Generative Pre-trained Transformer. Let's break that down:

Generative: It generates content like text, code, or even images.
Pre-trained: It has already learned from huge amounts of data before being used.
Transformer: A model architecture that understands the relationships between words.

GPT predicts what comes next in a sentence by analyzing patterns in the data it was trained on.

How Does an LLM Work?

Let's walk through the three main phases of how a language model processes and generates language.

Phase 1: Understanding the Input

This is where the model begins to process your prompt and understand what you're saying.

Tokenization

The first step is breaking down your sentence into smaller units called tokens, which may be words or sub-words.

"Today is a sunny day" → [Today, is, a, sunny, day]

These tokens are then converted into numbers so the model can work with them mathematically. Each model has its own tokenization method and a fixed vocabulary size (the total number of unique tokens it understands).

Try out this code, or you could visit here; to see different tokens by different models.

import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o")

text = "Hello, I am Shane" #Input Sequence

tokens = enc.encode(text)
print("Tokens: ", tokens ) #[13225, 11, 357, 939, 99388]

encodedTokens = [13225, 11, 357, 939, 99388]

decodedText = enc.decode(encodedTokens)
print("Decoded Text: ", decodedText) #Hello, I am Shane

Vector Embeddings

After tokenization, each token is mapped to a vector, a string of numbers that represents its meaning.

Suppose, I mention the words "Cat", "Dog", "Pedigree", "Dog Food", "Milk", "Cat Food". Noticed you pictured these words in your mind while reading them.

Embeddings give more context to a word, like showing a meaning rather than just a spelling.

Try this code out, to see how vector embeddings would look like;

from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()

client = OpenAI()

text = "Today is a sunny day."

response = client.embeddings.create(
    model="text-embedding-3-small",
    input=text
)

print("Vector Embeddings: ",response)
print("Length", len(response.data[0].embedding)) #Dimensions (3D = 3 Dimensions)

Positional Encoding

Since transformers look at the whole sentence at once (instead of word-by-word), they need to understand the position of each word. Positional encoding give this structure, they tell the model the order in which words appear.

"He went to the bank to get some money."

"They had a picnic by the river bank."

Without positional encoding, the model might confuse the two meanings of the word "bank."

But with it, the model understands that "bank" means a financial institution in one case and a river's edge in the other, based on surrounding words and their positions.

Semantic Meaning

Embeddings don't just turn words into numbers, they also capture the relationships and meanings behind those words.

This is what allows the model to understand that some words are closely related, while others are not.

Examples:

The vectors for king and queen are close to each other, just like man and woman, because they share similar meanings.
But the vectors for pizza and shoes are far apart, those words aren't related in meaning, so their embeddings reflect that distance.

Transformers: The Core of Modern AI

Transformers are at the heart of all modern LLMs.

Originally introduced by Google in 2017 to improve Google Translate, transformers have since become the foundation of nearly every major AI models.

Their research was published in the paper “Attention Is All You Need”

Here's why they matter:

"He swung the bat at the ball.
"A bat flew out of the cave."

Even though both sentences contain the word “bat,” you understood its meaning differently in each. That's context, and transformers are built to capture it.

Unlike older models that processed words one at a time, transformers look at the entire sentence all at once. This allows the model to understand how words relate to each other, regardless of their position.

That's how transformers help LLMs understand not just the words you use, but what you actually mean.

Phase 2: Processing the Input

This is where the model makes sense of the input and begins reasoning about it.

Encoder

The encoder helps the model understand what you've written.

It takes the input tokens and their embeddings (which include meaning and position) and transforms them into deeper representations that capture the sentence's full meaning and context. These internal representations are used by the model to figure out what you're trying to say.

"She unlocked the door with a key."

The encoder understands how each word is connected, that "she" did something, "unlocked" is the action, and "key" was the tool. It doesn't just read words, it also understands the structure and relationships behind them.

Self-Attention

Self-attention is a key feature of transformers. It allows the model to look at all the words in a sentence at once and figure out how much attention each word should pay to the others.

"She poured coffee into the cup."

The model learns that the word "poured" is closely related to both "coffee" and "cup", because they all contribute to the action being described.

This helps the model understand which words matter most in context, rather than just reading one word at a time.

Multi-Head Attention

Multi-head attention is like a team of specialists working in parallel. Each "head" looks at the sentence from a different perspective:

One might focus on grammar
Another might look at context
Another might track relationships between specific words

Each head captures something unique, and when combined, they give the model a richer and more complete understanding of the input.

Softmax

Once the model processes the input, it generates a score for every possible next word.

Softmax turns these raw scores into probabilities, like a voting system. The higher the score, the more likely that word is to be chosen.

The word with the highest probability (most "votes") is selected as the next word in the response.

Temperature

This controls how creative or predictable the model's responses are:

Low temperature → safe, reliable responses
High temperature → more random, creative answers

It’s like adjusting a thermostat for imagination.

Phase 3: Generating a Response

Now that the model understands your input, it's time to respond.

Decoder

The decoder takes what the model has understood and starts generating a response, one word at a time, like a builder laying bricks to form a sentence.

Input: "The sky is..."

Output: "blue."

Each word is chosen based on the context of the previous ones to keep the response natural and meaningful.

Inference

Inference is the moment the model replies.

No new learning happens here, the model isn't updating or training anymore. It's simply using what it already knows to generate a response based on your input.

Think of it like a chef following a recipe they've already mastered, just applying what they've learned.

Knowledge Cutoff

AI models aren't connected to the internet in real time. They can't look up new facts or news. They only know what they were trained on, up to a specific point in time, called the knowledge cutoff.

It's like a photo album frozen in time. Anything that happened after that date is missing, unless the model is retrained or updated.

Final Thoughts

AI isn't magic. It’s just a very smart system trained on patterns from massive amounts of data.

Once you understand a few key ideas, like tokens, vectors, attention, and decoding, you'll start to see how LLMs like ChatGPT actually work.

Enjoyed this post?
Found it helpful? Feel free to leave a comment, share it with your team, or follow along for more.

🌐 shanedsouza.com

Why 100 Lines of Code Can Be Better Than 2

Shane Dsouza — Wed, 21 May 2025 04:22:13 +0000

In programming, it's easy to assume that shorter code is better code. It looks clean, compact, and clever, and we might believe it uses less memory, and runs faster.

But here's the catch:

Shorter doesn’t always mean smarter or more efficient.

Sometimes, a few extra lines of code can outperform a clever one-liner, especially when it comes to reducing costly operations.

Let’s look at a real-world analogy to make this clear.

📦 Product Boxes at a Factory

9 identical product boxes are ready to ship. One of them has a manufacturing defect, it's heavier because it contains extra metal parts.
Your task is to detect and remove it before quality inspection fails.

Approach 1: Straightforward

You weigh each box one by one.

int boxes[9] = {1, 1, 1, 1, 1, 1, 1, 4, 1}; // 4 is the heavier box

for (int i = 0; i < 9; i++) {
    if (boxes[i] > 1) {
        return boxes[i];
    }
}

Number of weigh-ins: Up to 9
Efficiency: Low — especially if the heavy box is at the end.

Approach 2: Smart Approach

Split the 9 boxes into 3 groups of 3 and compare their total weights.

int boxes[9] = {1, 1, 2, 1, 1, 1, 1, 1, 1}; // 2 is the heavier box

int group1 = boxes[0] + boxes[1] + boxes[2];
int group2 = boxes[3] + boxes[4] + boxes[5];
int group3 = boxes[6] + boxes[7] + boxes[8];

if (group1 == group2) {

    // Faulty box is in group3
    if (boxes[6] > boxes[7]) 
          return boxes[6];
    else if (boxes[7] > boxes[6]) 
          return boxes[7];
    else 
          return boxes[8];

} else if (group1 > group2) {

    // Faulty box is in group1
    if (boxes[0] > boxes[1]) 
          return boxes[0];
    else if (boxes[1] > boxes[0]) 
          return boxes[1];
    else 
          return boxes[2];

} else {

    // Faulty box is in group2
    if (boxes[3] > boxes[4]) 
          return boxes[3];
    else if (boxes[4] > boxes[3]) 
          return boxes[4];
    else 
          return boxes[5];
}

Number of weigh-ins: Just 2 or 3
Efficiency: Much better, faster fault detection.

Conclusion

While concise code can be elegant, it's not always the most effective solution. As we've seen, a longer approach can significantly improve performance and clarity.

Short code isn’t automatically good code.

What's more important is whether your solution is readable, maintainable, and efficient.

Enjoyed this post?
Found it helpful? Feel free to leave a comment, share it with your team, or follow along for more.

🌐 shanedsouza.com

Commit To Code: Working with Git Pull Requests & Conflict Resolution

Shane Dsouza — Mon, 21 Apr 2025 04:28:01 +0000

📚 Git & GitHub Series

➡️ You're reading Part 5

⬅️ Part 4: Branching, Merging, Squashing & Rebasing

Working with Pull Requests & Conflict Resolution

Pull Requests (PRs) are the heart of collaborative coding. Whether you're working solo or on a team, understanding how to open, review, and resolve conflicts in PRs is a crucial skill.

What is a Pull Request?

A Pull Request (PR) is a request to merge code from one branch into another (usually into main). PRs are managed on platforms like:

GitHub
GitLab
Bitbucket

Think of a PR as saying:

“Hey team, I’ve finished some work. Can you review and approve it before we add it to the main codebase?”

Creating a Pull Request on GitHub

Step 1: Create a Feature Branch and Push Your Changes

git checkout -b feat/user-login
git add .
git commit -m "Add user login feature"
git push --set-upstream origin feat/user-login

We then check the commit history:

Step 2: Visit GitHub

GitHub will show:

“This branch is X commits ahead of main. Compare & pull request.”

Click Compare & pull request

Fill in:

A clear title
A description of what the PR does (Markdown and checklists work great!)

Click Create Pull Request

What Happens After Creating a PR?

Your teammates review your code
They may **comment, request changes, or **approve*
Once approved, it gets merged into main (usually with a regular or squash merge)

Conflict Resolution in Git

Conflicts happen when two branches change the same part of a file differently. Git can’t decide which version to keep, so it flags a merge conflict.

Resolving Conflicts Safely in a PR

Sometimes your PR shows conflicts with main after it's already created.

Strategy: Merge main into your PR branch
This keeps the PR alive and lets you fix conflicts cleanly.

Option A: Fix Inside Your PR Branch

git checkout feat/user-auth
git pull origin main
# Resolve conflicts
git add .
git commit -m "Resolve conflicts with main"
git push

Option B: Fix Using a Temporary Helper Branch

This is cleaner and more review-friendly.

# Step 1: Switch to your PR branch
git checkout feat/user-auth

# Step 2: Create a helper branch
git checkout -b feat/user-auth-merge-fix

# Step 3: Merge main into it
git merge main
# OR rebase if preferred:
# git rebase main

# Step 4: Resolve conflicts
# Step 5: Commit the resolution
git add .
git commit -m "Resolved conflicts with main"

# Step 6: Push the helper branch
git push origin feat/user-auth-merge-fix

Then, create a new PR from feat/user-auth-merge-fix → feat/user-auth.

Once merged, your original PR is conflict-free and ready to go.

Why This Strategy Works

Keeps your PR branch clean
Lets you resolve conflicts independently
Makes the fix reviewable as a separate PR

Simulating a Merge Conflict

1. From `main`, create a shared file:

echo "Hello World" > hello.txt
git add hello.txt
git commit -m "Initial hello.txt"
git push

2. Branch A (Developer A):

git checkout -b feat/greeting
echo "Hello from branch A" > hello.txt
git commit -am "Branch A greeting"

3. Branch B (Developer B):

git checkout main
git checkout -b feat/salutation
echo "Hi from branch B" > hello.txt
git commit -am "Branch B greeting"

4. Now merge both into main. The second merge will trigger:

CONFLICT (content): Merge conflict in hello.txt
Automatic merge failed; fix conflicts and then commit the result.

Fixing the Merge Conflict

1. Open the conflicted file. You'll see:

2. Edit the file to combine or choose changes:

3. Mark it as resolved:

git add hello.txt

4. Commit the resolved merge:

git commit -m "Resolve merge conflict between feat/greeting and feat/salutation"

Best Practices for Conflict Resolution

Pull often from main to stay up-to-date:

git pull origin main --rebase

Keep PRs small and focused
Use clear commit messages when fixing conflicts
Avoid editing the same file as others if possible

Wrapping Up

In this article, you learned:

What a Pull Request is and how to open one
How to handle team feedback and approvals
What merge conflicts are and how to resolve them
How to handle conflicts cleanly with helper branches
Best practices to reduce and manage merge conflicts

Using PRs effectively will help you collaborate confidently, maintain a clean main branch, and avoid headaches when merging code.

📚 More from the Series

Part 1: Why Git & GitHub Matter
Part 2: Setting Up Git and GitHub
Part 3: Creating Commits & Exploring the .git Folder
Part 4: Branching, Merging, Squashing & Rebasing
✅ Part 5: You're here!

Enjoyed this post?

Found this helpful? Drop a comment, share it with your team, or follow along for the next deep dive.

🌐 shanedsouza.com

Commit to Code: Branching, Merging, Squashing & Rebasing with Git & GitHub

Shane Dsouza — Mon, 21 Apr 2025 03:16:39 +0000

📚 Git & GitHub Series

➡️ You're reading Part 4

⬅️ Part 3: Creating Commits & Exploring the .git Folder

Understanding Branching with an Analogy

Think of a branch in Git as a railway track.

Each commit is like a rail car placed on that track, and the branch name (e.g., main) is the track's label.

Now let’s imagine two developers, Developer A and Developer B, working on their respective features.

Why Not Work on the Same Branch?

If both developers work directly on the same branch (main), over time the commit history gets polluted.

Now imagine if we need to revert Developer A’s changes, doing so would also affect Developer B’s work.

This is why we avoid working directly on main and instead create branches.

How Branching Helps

At the beginning, the HEAD (which points to the latest commit) is on the last commit of the main branch.

Developer A needs to work on a new feature.
They create a new branch from main using:

git checkout -b feat/a

Developer A commits code into feat/a, creating 3 commits.

Meanwhile, other contributors may add commits to the main branch, moving its HEAD forward.

When Developer A completes their work:

The feat/a branch is merged back into main.
The merge can happen in one of two ways:
As individual commits
As a single commit using squash:

git merge --squash feat/a

Real-World Git Rules (In Companies)

Different organizations follow different Git workflows, but a common approach includes:

The main branch is treated as the Single Source of Truth.
Developers never push directly to main.
Instead, they follow a similar process to this:
Create a feature branch (e.g., feat/login).
Push it to the remote repository.
Open a Pull Request (PR) to merge into main.
The PR is reviewed, discussed, and approved.
After approval, it gets merged into main.

This keeps the main branch clean, stable, and production-ready.

Branch Naming Conventions in Companies

To maintain clarity and consistency across teams, branches are often named following specific patterns:

git branch "feat/whatsapp-integration" #New feature
git branch "bug/login-not-working" #Fixing a bug 
git branch "wip/wontBeFinishedSoon" #Work in progress
git branch "junk/experimenting" #Temporary or experimental work

💡 Best Practices for Branch Naming:

Always use lowercase letters and hyphens - to separate words.
Start the branch name with a category prefix (feat/, bug/, wip/, story/, junk/).
Keep branch names short but descriptive.
Avoid using spaces or special characters other than - and /.

A consistent naming convention makes it easier to automate workflows, review pull requests, and manage releases.

Let's Perform Branching & Merging in Git

Follow along with this hands-on example to understand branching, committing, and merging.

Step 1: Check Which Branch You’re On

To see your current branch:

git branch

You’ll likely see main (or master).
If you’re not on main, switch to it:

git checkout main

Step 2: Create a New File and Commit

Create a file named feat-a.html and add some text inside the <body>.

Then stage and commit the file:

git add feat-a.html
git commit -m "Working on feat/a"

Step 3: Create a Branch from `main` and Switch to It

Let’s say you want to start working on Feature B:

git checkout -b feat/b

This:

Creates a new branch feat/b
Checks out into it (i.e., switches to it)
Sets HEAD at the last commit from main

Step 4: Make Changes and Commit in the New Branch

Create a file called feat-b.html, add some content in it, and make two commits:

git add feat-b.html
git commit -m "Added feature b file"

Make another small change, then:

git commit -am "Updated feature b file"

Step 5: View the Commit History

You can view commit history in two ways:

git log

Or a simplified version:

git log --oneline

Step 6: Merge `feat/b` into `main`

Now that your work is done in feat/b, let’s merge it back to main:

git checkout main
git merge feat/b

Your changes from feat/b are now part of the main branch.

Step 7: Create a New Branch and Switch in One Command

This is a shortcut to create and move into a branch:

git checkout -b feat/c

Make some changes in feat/c, then:

git add feat-c.html
git commit -m "Added feature c"

Then merge into main:

git checkout main
git merge feat/c

Step 8: View Your Updated Commit History

After the merges:

git log --oneline

You’ll see the new commits from feat/b and feat/c as part of the main branch history.

Delete Merged Branches (Recommended)

To keep your branch list clean, delete branches that have already been merged:

git branch -d feat/b
git branch -d feat/c

This won’t delete any history, your changes are already part of the main branch.

What Is a Squash Merge?

Squashing is a hybrid merging approach where multiple commits are combined into a single commit at the time of merging a branch.

When you merge a feature branch into main using squash, Git adds all changes but keeps the main branch history clean.

Benefits of Squash Merging:

Clean history – Only one commit added to main
Removes noise – No clutter from WIP commits or small fixes

Disadvantages of Squash Merging:

History is lost – You lose visibility into the original commit timeline
Harder to debug – Can be challenging if something goes wrong and you need fine-grained history

Try It Yourself: Squash Example

Create a new branch:

git checkout -b feat/d

Create a file feat-d.html, and make 4 commits with different content.
View the commit log:

git log --oneline

You’ll see 4 separate commits in feat/d.

Now Squash the Branch into Main

Switch to the main branch:

git checkout main

Perform a squash merge:

git merge --squash feat/d

Git will stage all changes from feat/d. Now create a single squashed commit:

git commit -m "Squashed: Feature D implementation"

Check the updated commit log:

git log --oneline

You’ll see just one new commit on main.
The 4 commits from feat/d are not shown separately.

Visual Breakdown

Let's break down how a branch is created and how merging works with and without squash.

Creating the Branch

Regular Merge

Squash Merge

Real-World Scenario: GitHub Flow with Squash

Let’s say your branch is 3 commits ahead of main.

1. Create a Feature Branch

git checkout -b feat/z

2. Make 3 Commits and Push

git push --set-upstream origin feat/z

Once pushed, GitHub will show:

"3 commits ahead of main"

3. Open a Pull Request

Suppose your organization has locked the main branch — you can't push directly.

So, you'll create a Pull Request by clicking "Compare & pull request" on GitHub.

4. Choose Squash & Merge

To merge cleanly into main, select "Squash and Merge".

This will:

Combine all 3 commits into one
Add a clean commit message to main
Automatically link the PR (e.g. #3)
Leave the feature branch (feat/z) visible until deleted

This keeps the main timeline clean while retaining traceability via the PR number.

5. Pull the Latest Changes to Your Local `main`

After merging the PR, update your local repo:

git checkout main 
git pull origin main

By following this squash-based GitHub flow, your history stays clean, yet your collaboration remains fully traceable.

Git Rebase

Rebase is powerful, clean, and dangerous if misused.
It rewrites commit history by placing your branch commits on top of another branch (usually main).

When to Rebase?

You're working on a feature branch
main has moved ahead
You want your branch to reflect the latest changes before merging

Common Mistake

If you’re on feat/b, avoid this:

git merge main  # This works but pollutes the history

Or:

git merge --squash main  # Uncommon usage, may not behave as expected

Correct Way: Rebase

git checkout feat/b
git rebase main

This replays your commits on top of the latest from main, keeping your history linear and clean.

Best Practice for Merging Into Main

To keep the main branch clean and organized:

git checkout main
git merge --squash feat/b

This brings in all the changes from your feature branch as one commit and avoids clutter in the commit log.

Wrapping Up

In this article, you learned:

Why branching is essential for clean, collaborative development
How to create, switch, and merge branches safely
The difference between regular merges and squash merges
How teams manage contributions using Pull Requests
The role of squash merges — both in GitHub and locally
How git rebase can help you keep a linear commit history
Real-world branch naming conventions used in professional workflows

By applying these concepts, you’ll keep your repository organized, your main branch production-ready, and your team collaboration smooth.

📚 More from the Series

Part 1: Why Git & GitHub Matter
Part 2: Setting Up Git and GitHub
Part 3: Creating Commits & Exploring the .git Folder
✅ Part 4: You're here!
Part 5: Working with Pull Requests & Conflict Resolution

Enjoyed this post?

Found this helpful? Drop a comment, share it with your team, or follow along for the next deep dive.

shanedsouza.com

Commit to Code: Creating Git Commits & Exploring the .git Folder

Shane Dsouza — Sun, 20 Apr 2025 03:36:45 +0000

📚 Git & GitHub Series

➡️ You're reading Part 3

⬅️ Part 2: Setting Up Git and GitHub

Getting Started with Git Tracking

Create a folder named Git-Learning and add a file (e.g. hello.txt) with some text.

At this point, Git is not tracking this folder or file. Git doesn’t track every folder on your machine by default — you need to initialize it.

Initializing Git

To allow Git to start tracking this project, run:

git init

Git now tracks this folder.

You'll see a U next to the file name, meaning Untracked.

How Does Git Track?

Once git init is run, Git creates a hidden .git folder — the brain of Git. It contains everything about your project's history.

Staging Files

When a file needs to be tracked it is moved over to the Staging Area.

To track a specific file:

git add hello.txt

To track all files:

git add .

Now files will show A, meaning Added to staging.

What’s Inside the .git Folder?

Some key components:

index — tracks files in the staging area.
objects — where Git stores commit data.
HEAD — points to the current branch or commit.

Let's try reading the index file:

Use this to view what's staged or untracked:

git status

Git reads from the index file to show you what's staged, modified, or untracked.

Creating a Commit

A commit is like a snapshot of your code at a specific moment:

git commit -m "Initial commit"

Each commit generates a unique hash ID and stores:

Author name and email
Date and time
Commit message Reference to the previous commit (if any)

To view the commit history:

git log

Making Changes

Edit hello.txt, then check what changed:

git diff

Git tracks the difference between the working directory and staging area using metadata inside .git.

Diving into the Objects Folder

Inside .git/objects, Git stores:

Blobs (file content)
Trees (directories)
Commits (snapshots)

The folder names are based on the first 2 characters of the SHA-1 hash of the file or commit.

Viewing Commit Data

You can use the commit hash to view commit details:

Notice, I can now see the who committed details, using the commit Hash ID.

Now I want to see the content in the file;

I will now use the blob ID to see the content in “file1.txt” that was committed.

Git stores everything in the .git folder — and you rarely need to manually look inside, because Git gives us tools like:

git stat
git diff
git log

Committing

Create another file, say file2.txt, add some content, then:

git add file2.txt
git commit -m "Added file2.txt"

Check the commit log again:

git log

You'll notice the HEAD is now pointing to the latest commit (Commit 2).

How Git Stores Commits

Every commit contains a SHA-1 hash, generated based on:

The content of the files
Previous commit
Commit message
Metadata

This ensures every commit is unique, even if you commit the same code again, you’ll likely get a different hash.

🧠 Git = Content-addressable storage.

Fun Fact: Git Meets Algorithms

Spotify once used an algorithm named MAYA (Most Advanced Yet Acceptable) to recommend music.
While it was supposed to suggest songs related to your taste, a bug caused it to occasionally show completely unrelated tracks, and surprisingly, users loved the variety!

Similarly, Git’s algorithms may look simple, but the power lies in how uniquely and efficiently it stores and suggests changes.

Traveling Between Commits

To navigate through your commit history, first run:

git log --oneline

To compare differences between two commits:

git diff <commit1> <commit2>

Moving HEAD to a Previous Commit

Want to move back in time?
You can checkout an earlier commit using its hash:

git reset <commit-hash>

As we move the head to commit 1, the files that were in the latest commit (Commit 2) are in Changes now.

If you don't want the changes then;

git reset --hard <commit-hash>

Notice because file 2, was added after the second commit, it appears as a new Untracked file, even though it was committed.

To verify:

git log

GitHub: The Remote Repository

Sharing the .git folder allows others to see your commits. Instead, use GitHub!

Initially both developers will have the same content in “file1.txt”. Now when they both begin to work on it simultaneously there will be conflicts as both as using the same file. Now which file is the Source Of Truth ? For that pen drive won’t be needed, we can use Github.

Create a GitHub repo (e.g. Git-Masterclass)

Then, link your local project:

Use the push an existing repository from the command line commands

git remote add origin https://github.com/yourname/Git-Masterclass.git

Verify the remote was added by viewing the config file within the .git folder

To see the URLS of the remotes connected to the local git repository, both for fetching(pull) and pushing.

Follow the remaining commands on GitHub:

git branch -M main git push -u origin main

Now visit Github will be able to see “Commit 1”, which was on our local machine is now on github.

Wrapping Up

In this post, you learned how:

How Git tracks and stages files
How commits and hashes work
What lives inside the .git folder
How to view, reset, and compare commits
How to push changes to GitHub

📚 More from the Series

Part 1: Why Git & GitHub Matter
Part 2: Setting Up Git and GitHub
✅ Part 3: You're here!
Part 4: Branching, Merging, Squashing & Rebasing
Part 5: Working with Pull Requests & Conflict Resolution

Enjoyed this?

Let me know in the comments or follow me for the next post in this Git & GitHub series!

shanedsouza.com

Commit to Code: Setting Up Git and GitHub

Shane Dsouza — Sun, 20 Apr 2025 02:21:11 +0000

Git & GitHub Series

➡️ You're reading Part 2

⬅️ Part 1: Why Git & GitHub Matter

Installation and Setup

In this part of the series, we’ll walk through installing Git on your system, setting up your identity, and creating a GitHub account, everything you need to start tracking and sharing your code.

1. Installing Git

Windows

Go to git-scm.com and download the Windows installer.
Run the installer and click Next through the setup wizard (default settings are fine).
Choose Git Bash as your default terminal.
Finish the installation and verify Git was installed:

git --version

macOS

Option 1 – Install via Xcode CLI:

xcode-select --install

Option 2 – Using Homebrew:

brew install git

Verify installation:

git --version

2. Configuring Git with Your Identity

Once Git is installed, you should set your username and email. This information will be attached to your commits.

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

To verify your settings:

git config --list

This ensures that every commit you make is properly attributed to you, which is especially important when collaborating.

3. Creating a GitHub Account

If you don’t already have a GitHub account:

Visit https://github.com/join
Choose a username, enter your email address, and create a password
Follow the prompts to verify your email and complete your profile Once you’re signed in, you’ll be ready to start creating repositories and pushing code to GitHub.

You're All Set!
You now have:

Git installed
Your identity configured
A GitHub account ready to go

📚 More from the Series

Part 1: Why Git & GitHub Matter
✅ Part 2: You're here!
Part 3: Creating Commits & Exploring the .git Folder
Part 4: Branching, Merging, Squashing & Rebasing
Part 5: Working with Pull Requests & Conflict Resolution

Enjoyed this?

Let me know in the comments or follow me for the next post in this Git & GitHub series!

shanedsouza.com

Commit to Code: Why Git & GitHub Matter

Shane Dsouza — Sun, 20 Apr 2025 01:01:02 +0000

📚 Git & GitHub Series

➡️ You're reading Part 1

⏭️ Next up: Part 2 – Setting Up Git & Your First Commit

Think Google Docs, but for code. It automatically saves your work, tracks every change, and makes collaboration effortless, all without the fear of losing progress. Now imagine trying to code without a system like that. Sounds chaotic, right?

That’s exactly why Git and GitHub are essential in modern development. They make it easier to track changes, collaborate with teams, and avoid costly mistakes, like accidentally deleting an important file.

Git: Code Management

Git is a version control system that helps developers track and manage code changes over time.

It records each change like a timeline, making it easy to:

Review changes
Compare versions
Revert when something breaks

Example:

If a bug appears in version 90, you can quickly roll back to version 89 where everything worked just fine.

While other version control systems exist, Git has become the industry standard — known for its speed, flexibility, and massive community support.

GitHub: A Collaboration Platform & CLI Tool

When multiple developers work on the same project, things can get messy fast.

Let’s say Developer A and Developer B are both editing the same file with different functions. How do we avoid chaos and ensure everyone stays in sync?

We use a Single Source of Truth.

Single Source of Truth

A Single Source of Truth is a remote Git server that holds the official version of the code.

It can be hosted on:

AWS
Azure
Any remote machine with Git installed

Developers push their changes to this central server, and others pull the latest updates — keeping everyone aligned.

Public Git Servers

Instead of setting up your own server, you can use public platforms like:

GitHub
GitLab
Bitbucket

They’re powered by Git, but built for modern collaboration.

Working with GitHub

GitHub is a cloud-based platform where developers store and manage their code in repositories.

Think of a repository as a folder for your project — complete with code, history, and documentation.

Developers can pull code from these repositories to work on it locally, and once they’re done, they push the changes back to the repository with a message. This message records who made the change ("Developer A worked on this") and what was done, this action is called a commit.

This transparency allows teams to collaborate confidently, knowing exactly what changed, when, and by whom.

Wrapping Up

This is just the beginning of your journey with Git and GitHub.

In this article, you discovered what Git and GitHub are, and why they matter.

📚 More from the Series

✅ Part 1: You're here!
Part 2: Setting Up Git and GitHub
Part 3: Creating Commits & Exploring the .git Folder
Part 4: Branching, Merging, Squashing & Rebasing
Part 5: Working with Pull Requests & Conflict Resolution

Enjoyed this?

Let me know in the comments or follow me for the next post in this Git & GitHub series!

shanedsouza.com

DEV Community: Shane Dsouza

Prompting Techniques: How to Talk to AI (and Get What You Want)

Prompting Techniques

1. Zero-Shot Prompting

2. Few-Shot Prompting

3. Chain-of-Thought Prompting

4. Self-Consistency Prompting

5. Persona-Based Prompting

Final Thoughts

AI Buzzwords Decoded: What LLMs like ChatGPT Really Do

LLMs

GPT

How Does an LLM Work?

Phase 1: Understanding the Input

Tokenization

Vector Embeddings

Positional Encoding

Semantic Meaning

Transformers: The Core of Modern AI

Phase 2: Processing the Input

Encoder

Self-Attention

Multi-Head Attention

Softmax

Temperature

Phase 3: Generating a Response

Decoder

Inference

Knowledge Cutoff

Final Thoughts

Why 100 Lines of Code Can Be Better Than 2

📦 Product Boxes at a Factory

Approach 1: Straightforward

Approach 2: Smart Approach

Conclusion

Commit To Code: Working with Git Pull Requests & Conflict Resolution

Working with Pull Requests & Conflict Resolution

What is a Pull Request?

Creating a Pull Request on GitHub

Step 1: Create a Feature Branch and Push Your Changes

Step 2: Visit GitHub

Conflict Resolution in Git

Resolving Conflicts Safely in a PR

Simulating a Merge Conflict

1. From main, create a shared file:

2. Branch A (Developer A):

3. Branch B (Developer B):

4. Now merge both into main. The second merge will trigger:

Fixing the Merge Conflict

1. Open the conflicted file. You'll see:

2. Edit the file to combine or choose changes:

3. Mark it as resolved:

4. Commit the resolved merge:

Best Practices for Conflict Resolution

Wrapping Up

📚 More from the Series

Commit to Code: Branching, Merging, Squashing & Rebasing with Git & GitHub

Understanding Branching with an Analogy

Why Not Work on the Same Branch?

How Branching Helps

Real-World Git Rules (In Companies)

Branch Naming Conventions in Companies

💡 Best Practices for Branch Naming:

Let's Perform Branching & Merging in Git

Step 1: Check Which Branch You’re On

Step 2: Create a New File and Commit

Step 3: Create a Branch from main and Switch to It

Step 4: Make Changes and Commit in the New Branch

Step 5: View the Commit History

Step 6: Merge feat/b into main

Step 7: Create a New Branch and Switch in One Command

Step 8: View Your Updated Commit History

Delete Merged Branches (Recommended)

What Is a Squash Merge?

Benefits of Squash Merging:

Disadvantages of Squash Merging:

Try It Yourself: Squash Example

Now Squash the Branch into Main

Visual Breakdown

Real-World Scenario: GitHub Flow with Squash

1. From `main`, create a shared file:

Step 3: Create a Branch from `main` and Switch to It

Step 6: Merge `feat/b` into `main`

5. Pull the Latest Changes to Your Local `main`