When ordering food in a cafe, you go to the counter, place an order by making payment, and the cashier hands you a buzzer. You don't stand in front of the cashier while your order is being prepared, blocking the queue for everyone after you. You take the buzzer and sit down, scrolling through your phone until your order is ready. You are doing other tasks while the food is cooking in the background. When the food is ready, the buzzer rings and signals you to collect the food at the counter (this is promise resolving!), and now you go get the food. JavaScript deals with waiting the same way.

What Promises exactly are:

A Promise in JavaScript represents that an block of code will eventually be completed or failed and also represents the result value.

A promise has 3 states being:

1. Pending -> The initial state where the tasks has not yet been completed.

2. Fulfilled -> The task has been completed successfully.

3. Rejected -> The task has failed.

function prepareOrder(dish) {
  return new Promise((resolve, reject) => { 
    setTimeout(() => {
      if (!dish) {    //if no dish(argument) has been passed, reject state
        reject(new Error("No dish is there"));
        return;
      }
      console.log(`${dish} is ready`);
      resolve({ dish, status: "prepared" });
    }, 100);                //100 milli-second of delay has been added
  });
}

Promise.all()

The scenario:

Imagine a group chat is planning a weekend trip to Goa. For this trip to happen, there are four friends who want to go but there are certain conditions before going.

1. Ayush -> needs to get permission from his parents.

2. Himanshu -> needs to get his money back from a friend who he lended money, to fund hotels.

3. Ishan -> needs to bring his car.

4. Raj -> needs to just show-up. (he is lazy)

If Ayush and Himanshu are ready to go, but Ishan says that he cant get the car, then the whole plan is completely dead. You can't go on a partial trip without a car. It's everyone, or it's no one.

Translating the analogy to JavaScript

Promise.all() works in a similar way, where the group chat is Promise.all([Ayush, Himanshu, Ishan]) and .then is every single friend confirming that he is coming and the trip is officially on.

The Rejection (.catch): This is the important part of Promise.all() . As soon as Ishan says he can't get his car, the plan is cancelled immediately. The group chat doesn't care anymore if Ayush got permission or if Raj is coming. This is when .catch triggers and none of the other promises resolve.

const Ayush = Promise.resolve("Got permission, Let's go!.")
const Himanshu = Promise.resolve("Got the money! ")
const Ishan= Promise.reject("Couldn't get the car, Abba nahi maane 😭")
const Raj = Promise.resolve("Bags Packed, I am ready to go!")

Promise.all([Ayush, Himanshu, Ishan, Raj])
  .then((confirmations) => {
    console.log("The Plan is ON!, Pack your bags!")
  })
  .catch((reasons)=>{
    console.log("Trip cancelled because: ", reasons)
  })
//Output: Trip cancelled because: Couldn't get the car, Abba nahi maane 😭

If everything goes as planned and trip happens, then the result will be returned in an array of 'confirmations' in the same order as input.

Promise.allSettled() :

Acquiring food at a Wedding Buffet:

Imagine you are at a wedding along with three of your cousins. The buffet just opened and you have planned that each of you will go for different foot stalls to get every food fast.

• Cousin A goes for Live starter counter (Returns with Panner tikkas = fulfilled)

• Cousin B goes for the main course, but the tandoor broke down and he gets nothing (Fails to get Naan = rejected)

• Cousin C successfully secures Gulab Jamun (Returns with Gulab Jamuns = fulfilled)

If this was Promise.all() you would leave the wedding buffet as soon as tandoor broke down and Cousin B fails to get Naan and be starving, but here we use Promise.allSettled() here, you wait for all cousins to return with whatever they managed to get and just eat whatever survived the chaos.

const cousinA= Promise.resolve("Paneer Tikka secured");
const cousinB = Promise.reject("Tandoor broke down");
const cousinC = Promise.resolve("Gulab Jamun acquired");

Promise.allSettled([cousinA, cousinB , cousinC ])
  .then((plate) => {
    console.log("Time to eat! Here is what we got:");
    console.log(plate);
  });

/* OUTPUT:
Time to eat! Here is what we got:
[
  { status: 'fulfilled', value: 'Paneer Tikka secured' },
  { status: 'rejected', reason: 'Tandoor broke down' },
  { status: 'fulfilled', value: 'Gulab Jamun acquired' }
]
*/

Promise.allSettled() executes all the promise statements, both resolved and rejected. It does not care resolve or reject, it returns the result in an array in the same sequence as the original promise array.

Promise.race() :

The Scenario:

Imagine it is 2:00am and you are feeling lonely and you make the most chaotic decision of texting three of your exes with the same text "you up?". You hit send on all three at the exact same time.

• Ex A (The fast replier): Instantly replies in 0.5 seconds: "Do not ever contact me again, I am calling the police."(rejected)

• Ex B: Is currently typing (will resolve in 3 seconds with "I've missed you.")

• Ex C: Is fast asleep (will resolve in 5 hours with "Hey, just woke up, come over.")

Because Ex A was the fastest to reply, she wins the race.

Promise.race() takes the brutal rejection as the final answer for the entire night. It instantly throws your phone out of the window, you cry yourself to sleep all alone and lonely.

const exA = new Promise((_, reject) => {
  setTimeout(() => {
    reject("Blocked and reported");
  }, 500); //0.5 seconds
});

const exB = new Promise((resolve) => {
  setTimeout(() => {
    resolve("I missed you too <3");
  }, 3000); //3 seconds
});

const exC = new Promise((resolve) => {
  setTimeout(() => {
    resolve("Come over");
  }, 18000000); // 18,000,000ms = 5 hours
});

Promise.race([exA, exB, exC])
.then((reply)=>{
  console.log("Success! You got a late night date: ", reply)
  return
})
.catch((disaster) =>{
  console.log("Night ruined. Final result:", disaster)
}
)

// Output: Night ruined. Final result: Blocked and reported 
// (Notice how Ex B and Ex C are completely ignored because Ex A was faster)

This is exactly how Promise.race() works, race does not care if the promise is resolved or rejected, it just wants the promise which executes the fastest, Everything else that finishes after that is completely ignored.

Promise.any() :

The Scenario:

Suppose you are standing on the side of the road during evening rush hour. You need to get home, so you walk up to a line of three parked auto-rickshaws and ask them all if they will go to your area.

• Auto 1 (The VIP): Looks at you, shakes his head without saying a word and drives off (rejected instantly)

• Auto 2 (The Scammer): Tells you, "Meter se nahi jaunga, 300 lagenge." You refuse. (rejected after negotiation)

• Auto 3 (The Legend): Just nods, resets the meter and says, "Baith Jao." (fulfilled)

We do not care how many drivers rejected as long as atleast one of them says yes.

const auto1 = new Promise((_,reject) => setTimeout(() => {
  reject("Silently drives away")
}, 1000))
const auto2 = new Promise((_,reject) => setTimeout(() => {
  reject("Demands double the meter rate!")
}, 3000))
const auto3 = new Promise((resolve) => setTimeout(() => {
  resolve("Meter on. Let's Go!")
}, 5000))

Promise.any([auto1, auto2, auto3])
.then((ride)=>{
  console.log("Success! You got a ride home:", ride)
})
// Output: Success! We got a ride home: Meter on. Let's go! 
// Notice how it completely ignored the first two rejections!

Promise.any() ignores the number of rejections as long as there is at least one resolution. It fails only if all promises fail.

Choosing the Right Promise Strategy:

• Promise.all() is strict. It needs all of the promises to resolve and collapses even after one rejection

• Promise.allSettled() is realistic. It reports everything, whether resolution or rejection. It doesn't care.

• Promise.race() is impatient. The first outcome decides everything, be it rejection or fulfillment.

• Promise.any() is stubborn. It gives up when everyone says no.

In asynchronous JavaScript, the problem is not waiting,

it is waiting the wrong way.

CSS cannot apply styles without knowing where to apply a specific style. To style a specific element, there needs to be a unique identifier to select that specific element to be styled. Without, selector all styling becomes random or gets applied to the entire page. It is like addressing a crowd rather than calling someone specific using their name. Selectors are the foundation of CSS. For precise styling, CSS selectors are needed.

What is a CSS Selector?

Selectors in CSS are used to choose HTML elements. Selectors are the ones who decide who gets styled. Selector works as a filter deciding the specific element or group of elements which are going to be styled next. CSS has a set rule for selector, which says that while writing CSS, first comes the selector name and then comes the declaration block which decides the styling of the selected elements. An example of CSS selector is given below.

body{
background-color:red;
color:black}

Element Selector

Element Selector is used to select an element anywhere in the entire HTML document, the given element may have multiple instances and all of them will get styled at the same time. Syntax structure involves writing the name of the tag followed by a curly brace which holds the declaration block which decides the styling of the selected element. It is used for addressing an entire category. An example of Element Selector is given below.

It will make all the text in paragraph tag, red colored anywhere in the entire webpage.

p {
color:red}

Class Selector

The class selector uses the class attribute from HTML tags. They are accessed in CSS using . notation. They can be reused across multiple elements. One single element can have multiple classes. It is designed for reusable styling patterns. Some of the practical use cases of Class selector are in buttons, cards and layout components. It is really flexible with it usage in various elements. It is like calling everyone wearing a red shirt, when we use class to call every element from that class.

This is an example of HTML with class highlight.

<p class="highlight">Important text</p>

CSS using class selector for highlight class and adding a background colour yellow to it. It is shown how we used . notation to specific that it is a class.

.highlight {
  background: yellow;
}

ID Selector

The ID selector uses the ID attribute from HTML tags. They are accessed in CSS using # notation. It is used to target a specific element in the HTML. It is designed for targeted styling patterns. Some of the practical use cases of ID selector are in header and main section. ID should be unique for every page. It is used for single specific elements. It is like calling someone by their full name, when we use ID to call a specific element with that specific name gets styled.

This is an example of HTML with class highlight.

<h1 id="header">Welcome</h1>

CSS using ID selector for header id and changing the font size to 24pixels. It is shown how we used # notation to specific that it is using ID.

#header {
  font-size: 24px;
}

Group Selectors

Group selector is used to group several selectors into one rule. It is used to combine multiple selectors. It uses comma separated syntax. It is used to avoid repetition in CSS. It improves the readability and maintenance of the CSS.

The CSS below changes the font for all of the headings: h1, h2, h3.

h1, h2, h3 {
  font-family: Arial;
}

This would have been the CSS if we didn't use group selectors in CSS. Very lengthy and not clean. Think of it as addressing multiple groups with one announcement.

h1 {
  font-family: Arial;
}
h2 {
  font-family: Arial;
}
h3 {
  font-family: Arial;
}

Descendant Selectors

Descendant Selectors target elements inside other elements.

div p {
  color: green;
}

This styles only the paragraphs inside the div tag. It adds context to which paragraph is being styled, it does styling every paragraph but only specific ones based on location. An analogy for Descendant Selectors is like calling all the students inside Room A.

Basic Selector Priority

When multiple selectors target the same element, CSS decides using priority

ID > Class > Element

IDs have a higher priority compared to classes, while classes have a higher priority compared to elements.

This is called specificity, it prevents conflict between which style gets applied to an element.

HTML can be quite wordy, making developers spend a lot of time writing code. This is especially true with all the opening and closing tags HTML needs. It can become boring and take longer than designing and developing the webpage's features. For example, creating a navigation bar with 10 list items means typing each <li> tag, making sure every opening tag has a closing tag, and keeping the indentation right for easy reading. Developers also need to watch for and fix mistakes like missing tags or wrong nesting, which can slow things down even more. This repetitive and careful work can be both slow and frustrating, taking away from the creative side of web development.

This is the normal and manual HTML, very time consuming.

<ul>
    <li></li>
    <li></li>
    <li></li>
    <li></li>
</ul>

What if we could write this in one line? This is where Emmet comes into the game.

What is Emmet?

Emmet is a shorthand/shortcut language. It is built into most code editors. It is used to convert abbreviations into HTML/CSS. Emmet is like autocomplete for HTML, which is actually smart. It allows developers to write complex and nested HTML structures. Emmet is included in VS Code by default and in many other editors.

How Emmet works inside editors

Emmet works inside editors as a plugin that turns abbreviations into full, structured HTML or CSS code snippets. The expansion is triggered by pressing the Tab key. The plugin, i.e., Emmet, expands the abbreviation into a full, correctly formatted code block at the cursor’s location.

For example ul>li*3, the result is shown below:

Basic Emmet syntax

Creating elements:

Typing the tag name expands into that tag.

div-> <div></div>
p-> <p></p>
section-> <section></section>
header-> <header></header>

Classes and IDs:

This syntax gets converted into proper tags.

div.container
h1#title

The expansion for above shorthand syntax:

• . = class

• # = id

<div class="container"></div>
<h1 id="title"></h1>

Nested elements

There are several elements in HTML and CSS which are nested together to create a structure. Typing these elements manually is time consuming which is where Emmet takes the load off you.
In Emmet > operator is used to nest several elements together, this operator is used to indicate that the next abbreviation coming after the operator will be inside the first element’s opening and closing tag. An example of this is ul>li, this examples shows how li tag will be nested inside the ul tag and a similar example will be table>tr*3>td*2 and the result for this abbreviation is shown below. It creates a well structured table with 3 rows and each row having 2 columns.

    <table>
        <tr>
            <td></td>
            <td></td>
        </tr>
        <tr>
            <td></td>
            <td></td>
        </tr>
        <tr>
            <td></td>
            <td></td>
        </tr>
    </table>

Repeating elements

You must have noticed that we use *2 in the above abbreviation to create the tag multiple times and that is exactly how it works. You use * operator to multiply the occurrence of a tag.

Adding Attributes

While using Emmet, attributes to a certain tag can be added using [] operator, you write the tag name and then the attribute inside the [] operator and it gets converted into expanded form. An example for this is a[href="#"] this gets converted into <a href="#"></a>

Full HTML Boilerplate:

Emmet is used to get the essential and repetitive structure every web page needs. It uses ! to generate the necessary code which is needed in every page. Shown below is the code that gets generated by using !.

    <!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>Document</title>
    </head>
    <body>

    </body>
    </html>

Why Emmet matters for beginners

Emmet is essential for both beginners and experienced developers because it helps with faster typing and reduces syntax errors. Emmet allows you to focus on the layout instead of typing, and it encourages experimentation. While using Emmet is optional, once you learn it, you'll find it hard to stop using it.

Brower opens websites is the lay man definition, while what it actually does it way more interesting and important. A browser is a software that talks to servers by being the mediator between the client and the server, transferring the client’s requests and the server’s response. Browser understand HTML/CSS/JS and converts it and renders it for users to see it. Browser is displays the UI of the websites, used for networking by fetching files from the server, it has JavaScript engine to run JS, it also has data storage to store cache and cookies in local storage.

Main Parts of a Browser (High-Level)

• User Interface: The part that we click while on a website.

• Browser Engine: It acts as a coordinator or a manager between the server and client.

• Rendering Engine: It Turns code into visuals.

• Networking: It is used for fetching files.

• JavaScript Engine: It runs JavaScript.

• Data Storage: Cache, cookies are stored in local storage.

User Interface: Address Bar, Tabs, Buttons

UI or User Interface is the part of the browser which is interactive and the part that we click while using a browser. Elements like the Address bar, Back/forward, buttons, Tabs, Bookmark bar are parts of the browser UI.

Browser Engine vs Rendering Engine

Browser Engine

The Browser Engine acts as a middleman for the server and the client. It manages how they interact. When you type a URL or click a link, the browser engine sends the request to the server and waits for a response. Once the server sends back the data, the browser engine gives it to the rendering engine to display. This process makes sure all of the requests are handled and the right data is shown. The browser engine also deals with errors and manages the browser's cache to make browsing faster and smoother.

Rendering Engine

The Rendering Engine is a key part of the web browser that turns HTML and CSS code into what you see on your screen. When you open a webpage, it takes the HTML, which has the page's structure and content, and the CSS, which controls the style and layout. It uses this info to build a Document Object Model (DOM) tree, showing the page's structure. The rendering engine also quickly updates the display if anything changes, when you click on the page or when new content loads with JavaScript.

Networking: Getting the Website Files

Getting the Website files is a process carried out by the browser it involves various sequential steps.

1. URL of the website is entered.

2. DNS converts domain name into IP address.

3. HTTP request is sent to the server of the website.

4. Servers responds with HTML, CSS, JS and Images.

Browser downloads the files first and then processes them.

HTML Parsing and DOM Creation

Parsing means checks the syntax to understand the structure and then converting it into a structured format. HTML is read from top to bottom, meaning the syntax conversion starts at the top and moves toward the bottom. After the process of HTML parsing it creates DOM (Document Object Model). DOM is like a tree structure. It includes the root → Element → Children. It is like a folder structure including the root folder and then the subfolders that are followed in the absolute filepath.

CSS Parsing and CSSOM creation

CSS is handled by a special part called the CSS parser. This parser carefully checks the CSS code to figure out how the webpage should look. While doing this, it creates a CSSOM (CSS Object Model). The CSSOM is a detailed guide that includes rules for styling the webpage, like colors, font sizes, layout positions, and other visual details. This model is important because it decides how everything on the page will look. Even though the CSSOM is ready, nothing has rendered on the webpage yet. The display show up only after the DOM and CSSOM are combined, which allows the browser to display the content correctly.

How DOM and CSSOM come together

The Document Object Model (DOM) and the CSS Object Model (CSSOM) come together when the browser merges them together to form a render tree. This render tree is a visual representation of how the page should look like, which browser uses to perform layout and painting operations to display content on the screen. Render tree knows what to draw and how to draw it. It shows only the visible elements.

Parsing

Parsing is the process that takes raw characters from an equation and breaks it down into a structured format that a computer can compute. First, The parser identifies the tokens then, it builds a hierarchy to determine the order of operation, it can be simply said that it creates a tree of all the operands and operators. For example, in the expression (3 + 5) x 2, the parser identifies the parentheses as a priority and makes sure the computer adds 3 and 5 together before trying to multiply their result by 2.

Conclusion

When you type a URL, the browser manages everything from the first network request to the final display on your screen. It starts by getting raw files like HTML, CSS, and JavaScript from servers, then turns that code into internal models called the DOM (the structure) and CSSOM (the style). By putting these models together, the browser figures out the page layout and finally shows it as pixels on your screen. Knowing this process is very helpful for developers because it shows that the browser is an organized system with many parts, not just a "mystery box".

DNS stands for Domain Name System. DNS is used to map human-readable names to IP-addresses. DNS are useful because it is easier for us as humans to remember names rather than specific IP addresses to our favorite website, this is where DNS comes in to play, converting the names into IP-addresses. Without DNS, users would have to remember number of the IP address. DNS acts like a universal phonebook, people’s names are replaced with website names and telephone numbers are replaced with IP-addresses, only it is not accessible to us as is. Name resolution in DNS simply means converting domain names into IP addresses.

What is the dig command and when it is used

The dig command is a powerful DNS inspection tool that helps users query DNS servers to find out detailed information about domain name resolutions. This command is used in the terminal. When you run a command like dig google.com, you are asking the DNS servers to provide information on how to resolve the domain name google.com into its IP address. The output of the dig command has various sections, like the question section, answer section, authority section and additional section, each providing specific details about the DNS query and response process.

The dig command is used to

• Debug DNS issues.

• See which servers answer queries

• Understand the resolution flow.

Understanding dig . NS

The command dig . NS is used to identify the Root Name Servers that sits at the top of the DNS hierarchy. The specific . is used to select the root DNS and requesting for the NS (Name server) records. These root server do not know IP addresses. When this command is run, it return the 13 logical root servers that act as the starting point for resolving any web address. Root servers guide the resolver, they don’t resolve domains themselves.

Understanding dig com NS

While dig . NS looks at the top of the hierarchy, dig com NS focuses specifically on the Top Level Domain(TLD) servers related to .com. When this command is run, you are looking for authoritative name servers that manage all domains ending with .com. These servers act as the middle man in the DNS hierarchy, they don’t know the IP address of a specific site like google.com but they know exactly which name servers have that information. This is the second layer in DNS resolution.

Understanding dig google.com NS

Running the command dig google.com NS is the final level in the DNS hierarchy, the Authoritative Name Servers. Unlike the root or TLD servers, these specific servers hold the actual IP address for a particular domain. When you run this command, you are asking the internet, that which specific servers are the ones that manage the records for google.com. The answer points to Google’s own infrastructure like ns1.google.com which is where all specific records like IP addresses(A records) are stored and managed. These servers are the source of truth and the final answers come from here.

Understanding dig google.com

When you run a standard dig google.com without NS, you are asking for the full DNS resolution flow to find a specific IP address. Instead of asking who is in-charge of a server, you are asking for the A record, the actual location of the server.

The entire flow is shown in the diagram below.

The Full Resolution Flow is as follows:

1. Client asks recursive resolver.

2. Resolver queries root servers.

3. Root servers point to TLD(.com)

4. TLD points to google.com authoritative servers.

5. Authoritative servers return IP address.

6. Resolvers caches the result for later usage.

7. Client connects to IP.

Conclusion:

DNS Hierarchy is a structured phonebook that is used to delegate the traffic from the general servers to specific ones. Using dig at different levels allows you to see this personally. Understanding this flow is the key to troubleshooting why a website might be reachable for few people but appear to be down for others due to propagation or configuration errors.

A server is just a computer connected to the internet. Its job is to listen to the requests of the various clients and send responses according to the requests. When a website or app is opened, thes device sends a request to the server. The servers replies with data like HTML, JSON, images, etc. The website works because clients and servers talk to each other. Websites need data like pages, users, posts and apps need data like login, messages, products. All of this data lives on servers, not on our laptop. Client → Sends request and the Server → Sends response.

What is cURL?

cURL is a tool that lets you talk to the servers from the terminal. It sends requests the same way a browser does, but the only difference is browser hides everything behind UI while cURL show everything raw.

Why Do Programmers Use cURL?

cURL is widely used by programmer for various reason, it helps you see the real web, not the polished UI browser version. Some of the reason why cURL is used by programmers are:

1. It is used to test servers quickly.

2. It is used to test APIs without writing code.

3. It is used to understand how requests and responses work.

4. It is used to debug backend problems.

Making your first request using cURL

curl https://example.com

What happens when the above command is run in the terminal:
You send a GET request to example.com and then the server replies with HTML. cURL prints that HTML in the terminal. It look messy because Browsers can render HTML while cURL just prints the HTML. Nothing is wrong here, it is just how it works. It is simply sending a request to the server and getting a response back.

Introducing GET and POST

Get request

The Get request is used to get the data from a server and it is the default method in cURL.
Example: curl https://api.example.com/users
Means: The client is asking the server for the users.

Post request

The Post request is used to send the data to a server. This method is used for submitting forms, uploading files, adding new users to a server.
Example: curl -X POST https://api.example.com/users
Means: The client is sending or creating data onto the server.

Understanding Request and Response

Request = what you send

Request is what you send including where you send it, the URL and how it was send using the GET method or the POST method.

Response = what you get back

Response is what you get back after a request is sent onto a server. It includes the status code of the response, 200 meaning success while 404 meaning not found. It also includes the body of the website which is HTML and of APIs which is JSON

Using cURL to talk to APIs:

APIs are servers that return JSON as a response when a request is made to it, it does not return HTML like an average server. cURL is perfect for testing APIs. This makes them essential for building modern web and mobile applications, where data needs to be exchanged seamlessly between the client and server. It is widely used by backend developers to check if endpoints of an API work, check the exact responses and it is used to debug issues fast.
Example:

{
  "id": 1,
  "name": "Ayush"
}

Common mistakes beginners make with cURL:

• They forget to add https:// in the URL while using the curl command.

• They expect browser like output in the terminal.

• They get intimidated by the raw HTML and JSON.

• They copy paste commands without understanding the intention of using it.

• They think cURL is too advanced.

How does a browser know where a website lives? When a user types google.com, the browser needs an IP. This is where DNS comes into play, DNS solves the problem by helping the browser find the exact IP of the website. DNS is basically a phonebook of the internet. A regular phonebook has names of the people along with their phone numbers while the DNS has IP addresses corresponding to their domains. It converts names into IPs.
Examples: google.com → 142.XXX.XXX.XXX

Why DNS Records Exist

Usually, one domain name is used for several services like websites emails, verifications, etc. DNS records are used in this context. DNS records tell the internet what does what. There are several types of DNS record like A, AAAA, NS, CNAME, MX, etc. All of these records have different use cases and they are used separately to delegate their services using the same domain name. Each DNS record solves one specific problem.

NS Record:

NS record is a type of DNS record that specifies which servers are managing a domain’s DNS records. It is used to navigate traffic to the correct website or application. It informs DNS system which servers hold the IP address. NS records are great for delegating subdomains to specific name servers. They are managed by DNS hosting providers. They contain the domain name, the record type (NS), and the hostname of the name server such as ns1.example.com. NS records tell the internet which DNS server is in charge.

A Record:

A record is the fundamental alternative to human-readable domain names like google.com. A record converts a domain name to IPv4. It directs traffic to the server hosting the website, allowing users to access sites using domain names rather than complex IP addresses. The main purpose of A records is to point a domain to an IP address. It is specifically used for IPv4, while AAAA is used for IPv6. A domain can have multiple A records, which are often used for load balancing, where traffic is distributed across different servers. This is the most important record for websites.
Example: example.com → 93.184.216.34

AAAA Record:

Exactly the same as A but IPv6. IPv4 maps to 32 bit-IPv4 addresses while AAAA records map to 128bit-IPv6. A records are the standard for older networks, whereas AAAA records are required for modern IPv6 connectivity and faster networking.

CNAME Record:

CNAME record is short for Canonical Name, it is a type of DNS that maps an alias domain or subdomain to a canonical domain name, rather than directly to an IP address. It is essential for mapping subdomains to external services and simplifying DNS management when updating IP addresses. CNAME records must point to a domain name, never directly to an IP address. When a user visits a CNAME site, the DNS resolver looks up the target domain to find the final A record, which provides the IP address.

MX Record:

MX which stand for Mail Exchange is a type of DNS record that is used to reroute incoming mails to the correct mail server for a domain. It is used for email delivery, directing messages to specific servers like Microsoft 365 or Google workspace. The MX record indicates how email messages should be routed in accordance with SMTP(Simple Mail Transfer Protocol).

TXT Record:

A TXT record is a DNS record that stores human-readable or machine-readable text about a domain. It doesn't tell a computer where to go like an IP address, but instead holds text-based information for verification and security. It is essentially used for keeping notes that can be used to prove services like Google that you actually own the website or provide a list of "approved senders" to stop spammers from faking emails from your domain.

How all DNS records work together for one website

The NS Record is the city directory. It tells the world exactly which map to look at to find the building. Once you have that map, the other records guide the traffic:

• A Record (The Address): This guides browsers to the main front door which is the IP Address so they can enter the building.

• CNAME (The Redirection Sign): If someone asks for www, this sign says, "That is just the main building," and points them back to the A Record. It is a redirection for the same location.

• MX Record (The Mailroom): This tells postman to skip the front door and deliver letters to the back gate.

• TXT Record (The Security Badge): This is a public notice on the wall used for verification. It proves who owns the building and lists who is allowed to speak on its behalf.

HTML stands for Hypertext Markup Language, and it is used to create the basic structure of any website. When a browser loads a webpage, it doesn’t see design or logic. It only sees structure. HTML creates the structure and the outline for the content of the website. It has all the content the webpage has added in a semantic manner to be styled later using CSS.

What an HTML tag is

HTML tags are used to create the outline of the webpage. Tags are used to create HTML elements, which may contain content. Tags come with various attributes which are like extra properties that can be added to the tag, to increase its functionality.

Some of the Basic Tags are

• <p></p>:This is the paragraph tag, used to write content onto the webpage.

• <h1></h1>: This is the heading tag, which is used to create a heading on the webpage, this tag can range from h1 to h6

• <div></div>: This is the Division tag, used to create a division in the webpage, it is used to group elements together for layout or styling.

• <hr>: This is the Horizontal Rule tag, used to create a horizontal line to create a partition in the webpage.

• <br>: This is Break tag, used to break the current line and move the content to the next line.

Opening Tag, Closing Tag and Content

Opening tag, closing tag and the content are all combined to call an element of HTML. Opening tag is the opening part of a tag which is used toward the beginning. Let’s take an example to showcase the opening tag and the closing tag.

<h1>Content</h1>

Here, <h1> is the opening tag while </h1> is the closing tag, these two tags combine together to contain the content. Tags are like the walls of the box while content is the thing kept inside the box.

Self-Closing (void) Elements:

Void elements in HTML are unique because they do not contain any content between tags. These elements are self-contained and only require an opening tag, without the need for a closing tag. Examples of void elements include <br>, which inserts a line break in the text, and <hr>, which creates a horizontal line for separating content. These elements are used to structure the webpage without the need for content, making them efficient for specific tasks. Since they do not wrap any content, they help reducing the number of tags needed for certain functions.

Some of the Self closing elements:

• <hr>: Creates a horizontal line to separate content sections.

• <br>: Inserts a single line break.

• <img>: Embeds an image into the document.

• <input>: Used to create web forms and its behavior is defined by the type attribute.

Block-Level vs Inline Elements:

TCP is short for Transmission Control Protocol. TCP is a very reliable form of communication between two devices and it ensures the entire data is transferred. In TCP packets are sent in a numbered order, which helps in retransmission of missing packets. It does not prevent packet loss but recovers from it. It is used for important tasks like downloading/uploading data, webpages, etc. TCP is like sending a courier to a friend’s address, this ensures the entire data reaches the person safely, although it is slow.

TCP is used when reliable, ordered, error-checked delivery is needed in a network. It is used when a slight delay can be tolerated but correctness is the priority over speed. If TCP were not used, users might notice missing or corrupt data. When applications are expected guaranteed delivery, TCP is used. TCP is needed because it is made assuming the network is unreliable and faces issues like packet loss, connection drop, slowing down and rerouting traffic mid conversation. All of the packets do not take the same path, some routes might be fast while some might be slow changing the order in which packets were sent. They might be sent in the order 1→2→3→4→5 but are received in the order 4→5→2→1→3. TCP reorders the packets before sending them to the application.

Problems TCP is designed to solve:

• Packet loss:
  Data packets can be lost during transit due to congestion or unreliable network.

• Out of order delivery:
  Due to problems like packet loss, connection drop and rerouting traffic, packets are received in an out of order manner, meaning they are sent in a different order than the order they are received in.

• Unreliable network paths:
  Routes can be changed mid-communication, causing delay and drops.

• No reliability in IP
  The network does not guarantee delivery or correctness.

What is the TCP 3-Way Handshake

3-Way Handshake is the method TCP uses to confirm the connection before transferring the data starts. In this process, the client sends a SYN (Synchronization) message to the server. Once the server receives the SYN message, it sends back SYN-ACK(Synchronization-Acknowledgement) to the client signaling that the SYN was received and acknowledging. When the client receives back the SYN-ACK, it knows that the server is active and then the client send back an ACK(Acknowledgement) telling the server that the transfer can begin now, since the connection has been established. After this 3 way handshake containing SYN, SYN-ACK and ACK, continuous data/packet transfer starts. This exchange ensures that both sides are ready for reliable communication.

A great analogy to explain this is during an online meeting, when a person comes forward to speak. Their first words are “Am I audible?” which is similar to the client sending SYN. After this, the listeners signal them back telling them that they are audible, which is SYN-ACK in our case. This interaction is followed by the speaking saying something indicating that they will begin speaking, exactly the way client sends back an ACK before the data transfer starts.

Step-by-step working of SYN, SYN-ACK, and ACK

• Step 1: SYN

  The client send the SYN message to the server asking if it is ready to communicate

• Step 2: SYN-ACK

  The server sends back SYN-ACK to the client signaling that it is indeed ready for communication.

• Step 3: ACK

  The client sends back ACK to the server, telling the server that the transfer can begin now, since the connection has been established.

How data transfer works in TCP

The data transfer process in TCP works by breaking down the data into smaller segments. Each of these segments is sent separately. These segments are called packets. Each segment is given a sequence number. These segments are shared/transferred in a sequential manner, ensuring that the receiver gets them in the same order as they were sent. These sequence numbers are useful to tell when a certain packet has be lost during the transit. In TCP receivers send ACKs(Acknowledgement) to the sender to confirm received data. This is how TCP knows what arrived safely. If receiver doesn’t send acknowledgement (ACK) for a certain packet, then it is concluded that it went missing and sender retransmits the segment to the receiver. Even if packets are received in an un-ordered manner, TCP reorders them before they reach the application.

How a TCP connection is closed

When two computers are talking using TCP, both sides can send data. So, if one side is done sending the data, the other side might still have data left to send. If we just cut the connection, the last data might be lost and the other side might still be sending data leading to application getting incomplete results.

This is when FIN and ACK comes into play, FIN signals the computer that “Hey, I am done sending data” and ACK means “I understood that”

Step by step: How a TCP connection is closed:

• Step 1: FIN

  One side(assume client) sends a FIN packet, telling the server that I have no more data to send you. This means the client cannot send more data after this but the server can still send data.

• Step 2: ACK
  The server sends an ACK, telling the client that “I have received your FIN”
  Client-server connection is closed but server-client is still open.

• Step 3: FIN

  When the server is also done sending the data, it send back its own FIN.

• Step 4: ACK

  The client send the final ACK to the server, telling “I have received your FIN”

  This is when the entire connection is closed and no more data can be shared and both the sides are done.

Conclusion:

TCP exists because networks are unreliable and applications should not have to deal with packet loss, reordering or partial data.

From the 3-way handshake to reliable data transfer and graceful connection termination, TCP ensures communication is complete, ordered and correct.

This is why TCP is used for critical tasks like web browsing, file transfers and APIs is where correctness matters more than speed.

TCP is short for Transmission Control Protocol. TCP is a very reliable form of communication between two devices and it ensures the entire data is transferred. In TCP packets are sent in a numbered order, which helps in retransmission of missing packets. It does not prevent packet loss but recovers from it. It is used for important tasks like downloading/uploading data, webpages, etc. TCP is like sending a courier to a friend’s address, this ensures the entire data reaches the person safely, although it is slow.
UDP is short for User Datagram Protocol. UDP is a fast and comparatively less reliable form of communication. UDP does not share data in ordered manner and it does not worry about the lost packets. It is used for video streaming, video calls and even for online gaming. UDP is like shouting a message across a football field; the person might not hear it, and there is no confirmation if the person heard it. The only upside to this method is that it is fast.

Key differences between TCP and UDP:

When to use TCP?

TCP is used when reliable, ordered, error-checked delivery is needed in a network. It is used when a slight delay can be tolerated but correctness is the priority over speed. If TCP were not used, users might notice missing or corrupted data. When applications expect guaranteed delivery, TCP is used.
Use cases of TCP are:

• Web browsing

• Uploading/Downloading

• Emails

• API/Backend communication

  If TCP was not used web browsing would not be possible. If any packets go missing, they could contain crucial data about the webpage and it might corrupt the data.

• 

When to use UDP?

UDP is used when the speed of transfer and low latency is the priority. If accuracy of every packet is not the main concern, then UDP can be used. This makes UDP ideal for real-time applications like live video streaming, online gaming and video calls. TCP implements retransmission in case of lost packets but UDP remove the wait for retransmission entirely making it faster. If the data becomes useless if it arrives late, then UDP is used in this case.

Common real-world examples of TCP vs UDP

• Web Browsing (TCP): Missing packets would break the HTML/CSS and cause pages to load wrongly

• File Downloads (TCP): Downloading files with lost packets would corrupt the entire file.

• Video calls (UDP): Late audio and video frames are useless, so skipping them makes the playback smoother.

• Online gaming (UDP): In online gaming late possible are not only late but wrong and it would cause lag and incorrect gameplay.

What is HTTP and where it fits?

HTTP is an Application Layer Protocol. It is not reliable itself but uses TCP to achieve reliability. HTTP depends on TCP to move its data across the network. It cannot function on its own. TCP is responsible for establishing connection, breaking data into packets, ensuring packets arrive in the correct order and retransmitting the missing packets. TCP just moves the data, nothing else. While HTTP is responsible for defining the request and response format. It lays down ground rules on how the server and the browser talk.

Relationship between TCP and HTTP

HTTP is an Application Layer Protocol, while TCP is a Transport Layer Protocol. HTTP uses TCP to send and receive data. TCP takes care of sending the data and deciding how the data is sent to another computer. HTTP decides what has to be sent. TCP has no idea on what HTTP is sending and HTTP has no control on how TCP delivers packets. They cooperate, but they don’t overlap. HTTP is not a replacement for TCP. HTTP cannot work without a transport protocol but TCP can exist without HTTP. They solve different problems at different levels.

MODEM is short for Modulator Demodulator, which means a device that converts the analog signal of the internet cables that come to your home into a digital signal (Binary 1s and 0s). The computer can only work with a digital signal, which is provided by the modem through the conversion from analog to digital.

Incoming Data (Demodulation / Decoding):

When Netflix sends a movie video stream to your computer through the internet to your ISP, who sends it to your house using a cable. MODEM uses this physical signal and demodulates it, converting it into digital signal(Binary 1s and 0s) and sends the stream to your computer through a router or ethernet cable.

Outgoing Data (Modulation / Encoding):

When you click upload on Instagram to post an image, the image is sent from your device to the modem through a digital signal. This signal is then converted into a physical signal, which is sent to the ISP, who then sends the same analog signal to the Instagram servers.

Modem brings the internet into your house, it establishes a connection to ISP. While the router supplies the internet to your devices in the house

Internet → Modem → Router → Switch → Devices flow:

What is a Router and How It Directs Traffic?

We have seen how internet reaches from ISP to modem and gets decoded and is sent to the router to transmit it to various devices in the house. The primary role of router is to connect the two different networks together, Wide Area Network(WAN) (Internet) to the Local Area Network(LAN) in your house. Router acts as a decision point between WAN and the LAN. Every time a new connection is made router takes care of the transactions between your computer and the internet.

Router acts as the mediator between the internet and the devices. When any data is received on the modem it does not know which devices to send this data to, those data packets come with a destination IP address, router checks if that IP address in present in it’s LAN, if it is available then the data is sent to the respective device. Without router, every device in a LAN would get every data, even the one that is not meant for it.

Incoming Data:

When data incoming is under process, the data comes to the router in the form of packets. Every packet contains a destination address. It is the IP address where the data is supposed to end up.
Router check if the address is present in my LAN?
If Yes → Send the data to the respective device.
Router sends the data to that device only, without router every device would get all the data.

Outgoing Data:

When you press the upload on Instagram, packets of data are created with Source address(Your IP address) and the destination address(Instagram server). This is when the router check if the destination address is present in my LAN, if not then router sends the data to the MODEM and then IP and then to the internet.

Router is like a traffic police standing at the door of your house taking care of all the interactions you are going to have. If you order a pizza and the pizza deliver guy comes then how would he know where to deliver the pizza in a large building, this is where traffic police(router) check that you ordered the pizza and he takes the pizza from the guys and delivers it to you personally. This is why your computer is "safe" behind a router. If a bad delivery guy comes to the building, the Router stops them at the door and says, "Nobody ordered this," and sends them away. They never get near your actual room.

Switch vs Hub: How Local Networks Actually Work?

Hub is a multi-port repeater. It send any received data to all the devices by default. It works in a way like one to many fashion. When a laptop A wants to send data to laptop B using hub, what hub does is it takes the data sends it to device B and also to every other device like laptop C, D E, etc.

Switch intelligently transfer the data to the correct device using the MAC address(It is the hardware based address concerned with every network card). The data in switch is wrapped around Ethernet frame so that it can travel in LAN. This Ethernet frame has a source MAC address and the Destination MAC address and the payload(actual data)

What is a Firewall and why security lives here?

Firewall works as the gatekeeper, who takes care of the packets that are going to enter the network. It sits between the secure network(LAN) and the untrustworthy network(Internet). It check if a certain data is allowed to go into the secure network and also the outgoing traffic from our current secure network. Firewall takes care of inspection and decision. It checks things like the source address, destination address, port, etc. Firewall also control the apps that can access the internet and the servers that can talk to the databases. It prevents data leaks. There are two kinds of firewalls, there is a software firewall which comes in-build in most of the latest computers and there is a hardware firewall which is used to protect the servers from unwanted visitors and threats.

The network Firewall and a real structural firewall work in a similar fashion, where a structural firewall works by containing the fire in a building and avoiding it from spreading and causing more damage. Similarly, network firewall also has a fire to avoid entering our secure network and that fire in our case is the internet which is full of threats, hackers and viruses. The network firewall filters the incoming packets by their IP-addresses, certain addresses are allowed while the traffic from some addresses is filtered out or stopped from entering the network. The firewall does not filter out only on the basis of IP-addresses but also on the basis of other factors like domain names, ports, protocols and even keywords.

What is a Load Balancer and why scalable systems need it?

Load Balancer the name itself is self explanatory. It works to reduce the load on servers by distributing requests across available servers, so no one server gets load of client requests.In case a server goes down, the load is redirected to the other active servers. If a new server is added to the network, then the same load is redistributed among those servers. Since load balancer works with multiple server, the client get their request readily addressed even when certain servers might be down.

Load balancer is widely used in the development market, an example to explain it is that during diwali sale or yearend sale, the ecommerce websites get a really heavy traffic and this is when load balancer plays an important role by delegating the requests between all the available servers and providing a smooth experience to the users. Load balancer allows to dynamic addition or removal of servers from the network, ensuring that the system remains scalable. The main reason a load balancer is needed is because if a single server is used it gets bottlenecked and overwhelmed by large number of requests, to avoid this several servers are used along with a load balancer.

How all these devices work together in a real-world setup?

The internet comes to your home in network cables in form of physical signal which is decoded by the modem. Modem converts the physical signal received from the ISP to digital signal. Next comes the router which mostly has inbuilt firewall, so the router acts as the distributor for the internet packets, while the firewall acts as a safeguard which protects our system and network from threats and unwanted visitors. After all of this process, your open a website and your request leaves the computer. The request hits the website’s load balancer, which delegates the requests to various available servers. That server processes the request and the response travels the same path back. Modem, Router, Firewall, Switch, Hub are the part of our LAN, while the load balancer is an external device used at servers and users interact with the load balancer and the same load balancers deals with selecting a server for your request subject to availability of servers.

Git is a version control system that helps developers collaborate and keep track of all the changes made in the code over time. Git stores the project data such as who authored the commit and the timestamp of the commit in the repository.

Most people use Git as a magic box, where they know just a few commands and go about their tasks without understanding what exactly happens under the hood of Git. How it stores the changes and what the contents of the .git folder are not known by most developers who work on the surface level and don't dive deeply into understanding the workings of Git.

This specific article is meant to create a mental model of Git’s workings and is not going to be a command memorization cheatsheet. By the end of this article, you’ll know what Git stores, where it stores it, and how it tracks the changes.

What Is Git Really?

Git is a content-addressable file system. What does that mean? It means that at the core of Git is a basic key-value data store. You can add any type of content to a Git repository, and it provides a unique key that you can use later to retrieve the content.

Git doesn’t really track changes of the code-base but it takes a snapshot of the project whenever asked to do so. It does not track line-by-line differences of the project.

Everything in Git is stored using hash. Git uses SHA-1 hash function to generate unique identifiers (hashes) for all of its objects, such as commits, files (blobs), and directories (trees). These hashes are 40-character hexadecimal strings.

The commands in Git serve as a user-friendly interface that allows you to interact with the repository. However, the real magic happens in the background, where Git manages object storage. This means that when you use Git commands, you are actually communicating with an internal database that efficiently handles the storage and retrieval of data.

Understanding the .git folder:

Why the .git Folder Exists

.git is the hidden subfolder created after the command git init is run, this command initializes the repository creating a .git folder. It is the entire repository of the project. The .git folder is where all the data related to the project repository is stored and this folder is created in the current directory.

Deleting the .git folder means losing the entire version history of the project. It works as the internal database of the project. To understand Git, you must understand what’s inside .git.

Structuring of the .git Directory

• objects/ → The subfolder objects/ is the heart of the Git database. It stores all your content in a compressed format using a hash algorithm. Blobs, Trees and Commits are the part of the content saved in objects/

• refs/ → Short for “references.” Keeps track of where all the branches and tags are pointing. HEAD points to the latest commit.

• index/ → This is the staging area. It stores the information of the changes you had decided for the next commit. It acts as a middle-man between your working directory and your actual commit history

config → This file holds the repository's settings, like your name and email for commits, the default branch name, and any custom Git command shortcuts you’ve set up. It tweaks how Git works to suit the project’s needs.

Git Objects: Blob, Tree, Commit

Blob:

Blob stands for Binary Large Object. It is the simplest file and stores the content of a file and nothing else. A blob does not know its own name or where it lives in your folders. It only knows the stored data inside. Every time you change even a single character in a file. Git creates a new blob for that specific version, only if the content changes. The same content has the exact same hash. If you have 10 identical files in different folders, Git creates only one blob. This is why Git is so space-efficient.

Tree:

If a blob is an object, then a tree is the directory. It acts as a map that organizes your files. A tree object lists filenames and maps them to their respective blob hashes. It also stores file permissions. If a directory has not been changed between commits, Git just points to the existing tree object rather than creating a new one.

Commits:

The commit acts as the “wrapper” that ties everything together in a snapshot of the project at a specific moment. Every commit points to exactly one root Tree (representing your main project folder). It stores data like who, what, when, and why a specific change was made to the project. Most importantly, every commit points to the parent commit (previous commit). This creates a chain of all the commits made so far, which acts as a history of the project.

How Git Tracks Changes?

Git works as a version control system that tracks changes made to a project and helps developers work together. These changes are recorded in the .git folder when the git commit command is run after changes have been added to the staging area using the git add command.

What Happens Internally During git add:

Git has three stages:
1. Working Directory – your files on disk
2. Staging Area (index) – what you intend to commit
3. Repository (.git) – immutable history (objects)

git add moves the files to the staging area
git commit turns staged data into permanent history

Step by Step Process of internal working of git add:

1. Git reads the file content:

   Git looks at the actual bytes of file.txt.
   It does not look into the filename and not even the path, it purely looks at the content.

2. Git hashes the object:
   Git runs SHA-1 on the file’s content, this hash becomes the identity of the content.
   Same content → Same hash
   Different content → Different hash

3. Git creates a blob object(if needed):
   If a blob with this hash already exists → Git reuses it

   If not → Git writes a new blob into:

4. Git updates the index (staging area):
   Git writes an entry in the index:
   Filename
   Permission
   Pointer → blob hash

   Here, we are just telling Git that for the next commit, I want this version.

What Happens Internally During git commit:

1. Git reads the index:

   Git looks at:

   • all staged files

   • their blob hashes

   • directory structure implied by paths

2. Git creates Tree objects:

   Git builds:

   • trees for subdirectories

   • one root tree for the project

Each tree has:

• maps filenames → blob hashes

• stores permissions

Trees are also hashed and stored in .git/objects.

3. Git creates a Commit object:

   Now Git creates one commit object containing:

   • pointer to the root tree

   • pointer to parent commit

   • author, timestamp

   • commit message

This commit is hashed and stored.

4. Git updates HEAD:

   • HEAD moves to point to the new commit

   • Current branch ref updates to the same commit

Result of git commit:

• History grows

• Snapshot becomes permanent

• Previous commits remain untouched.

Conclusion:

Git might seem tricky because a lot of its processes happen in the background. However, once you understand what's inside the .git folder, it becomes clearer. Git is essentially a content-addressable database that keeps snapshots of your project using blobs, trees, and commits, all connected by hashes.

Commands like git add and git commit aren't magical, they are simply ways to interact with this structure. When you know what Git is doing internally, it's easier to fix errors, debugging becomes more straightforward, and workflows feel more dependable. Instead of just memorizing commands, you gain a clear understanding of how Git tracks changes, maintains history, and ensures everything is accurate. This understanding is what makes Git truly powerful.

The need for version control arises as the complexity of the project continues to increase. The code of the project is not written once; it continues evolving over time. A version control system helps manage the different versions of a project. As the software changes eventually, keeping track of all the versions can be challenging.

The version control system tracks all the changes made to the codebase. When a mistake occurs in the code or a bug is reported, the tracked versions are crucial. They help identify which change in the code led to the bug, making it easier to resolve. It allows you to compare the older version of the code against the newer version, which might have new features added later. It allows developers to revert to a previously stable version in case something goes wrong. The version control system allows multiple developers to collaborate on a project and make their own contributions to the codebase without risking overwrites. The version control system brings accountability to the development process by providing details like the timestamp and the author of the change.

Imagine you are working on a hackathon project and need to add a new feature. This is where the version control system becomes useful, as it saves the last working version of the project. Giving you the freedom to experiment with the feature while keeping the working version safe from any unnecessary changes. The famous version control system 'Git' was developed by Linus Torvalds while working on his ambitious project of the Linux OS. He faced similar problems during development and needed a tool to manage different versions of the project while allowing collaboration among multiple developers. This led to the creation of Git.

The Pendrive Analogy in Software Development

Having started programming before learning about Git, I used to share my program with friends on WhatsApp or upload the zip file of the project to the drive and send them the link. Using this method, my friend would debug the program and send it back to me. It was too time-consuming and inefficient, leading to the classic development problem of having multiple versions of the code like final_v1, final_v2, final_latest and final_latest_latest_v1.

This is where the classic pendrive analogy comes in. A developer writes the code, zips it, and copies it to a pendrive to share with a friend who will work on a new feature or debug and then return the pendrive. The problem arises when trying to identify what changes were made in the code.

A developer writes some code and encounters a bug, then zips the code to share with a friend who is supposed to resolve the bug. He moves the code to a pendrive and shares it with the friend. This friend writes some code and debugs the program, moving it back to the pendrive to share with the first developer. When the first developer opens the code, he sees that the bug has been resolved but is unable to identify what changes were made to the code. Merging the different changes created by two developers becomes even more complex when a third developer joins the project. Coordinating a single pendrive and managing the different versions from these developers is challenging. As the project grows, multiple versions appear, causing confusion about which one actually works.

Day 1 → project
Day 3 → project_final
Day 5 → project_latest_latest_v1
Day 7 → project_final_latest_latest_v1
Which one actually works?

Old Methods Used by Developers

• Exchanging project zip files

• Carrying code in pendrives between computers

• Sending updated files over email

• Maintaining backups in shared drives

• Keeping multiple folders for safety

Major Problems

• Accidental overwriting of teammates’ work

• Loss of pendrive leading to complete data loss

• Corrupted zip files

• No rollback mechanism

• No accountability

• No safe way to experiment

  

What Version Control Replaced

• Central repository instead of pendrive

• Commits instead of renamed folders

• Branches instead of duplicate files

• Pull/merge instead of manual copy paste

Conclusion

The version control system solves the pendrive chaos by providing a way to track changes made to the code along with the timestamp and author, bringing accountability to the work. Creates a sequential history of all the versions of the project, making it easier to pinpoint any specific change made to the code by any contributor. Today, Git is universally used by developers to manage their code. The pendrive problem wasn't really about storage. It was about lost work, broken collaboration, no history, and no trust in the process. With this understanding of the issues that existed before Git, let's move forward and explore "Git for Beginners: Basics and Essential Commands." Here, we will learn the core commands and workflows of a modern version control system.

Git is a distributed version control system and is essentially a code tracker in simple words. Git works in a way that it tracks the commits made to a code base making it easier to track and understand the changes developers made over time while working on the project. Git helps keep track of any additions or deletions made to the code as it tracks the various versions of the project. Git stores the project data such as who authored the commit, the timestamp of the commit and also the previous versions(history) of the project in the repository. GitHub is a remote version control system that acts as a server storing a copy of the Git repository and allowing you to collaborate with multiple developers. GitHub is the server where the data related to the changes is stored for access by collaborators. GitHub receives commits when you push them and allows others to pull those commits, showcasing collaboration.

2. Why Git is Used?

Working on a project without Git makes it difficult to track changes, undo mistakes, and understand how the code evolved over time. Problems like creating multiple copies of the project with different changes in each version and no coordination between them were faced by developers. Not using Git creates a fear of breaking the currently working code, which can prevent one from adding new features. Only if they use Git can they have a working version of the code saved and then freely experiment with the code to try adding new features. Even solo developers need Git because they may not remember the changes they made to the code yesterday, which adds a lot of friction to the programming process. Problems like not knowing which change broke the code can also occur.
Even team collaboration needs Git, as it allows them to work on the code simultaneously. Git records which developer made each specific change to the code, along with the timestamp, and this data is stored in the repository. GitHub, being the server hosting Git, allows for collaboration and provides clarity on who made a certain change to the code. In large codebases, it can be hard to find and identify changes made by any developer. Git helps by keeping track of every change and who made it.
Git was originally created by Linus while developing his Linux operating system when he needed a version control system to track changes made to the code. Having seen the problems that arise if Git is not used, let’s understand how Git actually solves them.

3. Git Basics and Core Terminologies

Repository:

Repository is the place where every change made on the code is stored. Repository can exist locally on a developer’s machine, and it can also exist remotely on platforms like GitHub. Git works locally, while GitHub stores the remote copies of the repositories. Once a commit is made, the changes to the code, the author of the commit, and the timestamp of the commit are stored in the repository.

Working Directory:

Working directory is the folder where our project exists and it contains the source code, README, and any other file that is currently being editing. The working directory is the current state of the project where files are being edited before being saved into Git’s history. Git does not save any file or change automatically unless a commit is made.

Staging Area:

Staging Area is the location where the change is stored before a commit is made. The staging area is the intermediate state between a working directory and a repository. Once a change is made to the code, the file is added to the staging area. After being added to the staging area, a commit is made, which stores the change in the repository.

Commit:

Commit is the snapshot of the project that is stored in the repository. A commit is created from the changes added to the staging area. Once a change is added to the staging area, it is committed, and then those changes are stored in the repository. A commit stores data such as the exact changes made to the code, the author of the changes, the timestamp of the commit, and links to previous commits.

Commit History:

Commit History is the record of all the commits made so far by the multiple programmers. All of the past commits are represented in a sequential manner, and each commit points to the previous one. Commit History represents the timeline of the project.

Branch:

Branch is the concept in Git that creates a separate line of development. Branching allows working on different features without affecting the original code. Using Git, different developers can create branches of the code and work on their own specific version of the code. This allows multiple developers to work on a single project simultaneously and on different features.

HEAD:

HEAD points to the latest commit. It represents the current state of the project in Git history. When a new commit is made, HEAD moves forward and points to the new commit. HEAD is essentially a pointer to the latest commit. The HEAD branch points to the branch currently being worked on.

4. Common Git Commands

Installing Git:

1. Navigate to the latest Git for Windows installer and download the latest version.

2. Once the installer has started, follow the instructions as provided in the Git Setup wizard screen until the installation is complete.

3. Open the windows command prompt

4. Type git version to verify Git was installed.

Essential Commands:

1. git init → Used to create a Git Repository, it runs only once per project.

2. git add → Used to add the current changes from working directory to the staging area, waiting to be committed.

3. git commit → Used to add the commit to the repository and saves any staged changes.

4. git revert → Used to create a new commit that undoes any unwanted changes made in an earlier commit by creating the complement of the commit.

5. git reset → Used to move the HEAD to a certain commit and optionally upstages or discards changes.

6. git log → Used to display the history of all the commits made so far.

7. git diff → Used to find the differences between two different commits, it is used to point what changed between those two commits.

8. git status → Used to show the current state of your working directory and staging area.

Basic Developer Workflow:

• A developer creates a project folder.

• Initialize Git using git init

• Edits files

• Checks state using git status

• Stages changes with git add

• Saves snapshot with git commit

• Views history with git log

The basic development workflow starts with creating a project folder, which is the working directory where all the files reside. This is the fundamental step in the development process. After creating the project folder, the folder is initialized using git init, which creates a repository where all the changes will be saved. The developer starts working on the project and checks the project state using git status. Once enough progress is made, the developer uses the command git add to add the changes to the staging area. Later, git commit is run to commit those changes and save them to the repository. After several commits, git log is used to see the history of all the commits made so far.

Diagrams:

1. Git Working Lifecycle:

2. Git Commit Timeline: