What is Git ? Git is a distributed version control system that helps track changes in source code during software development. Developed by Linus Torvalds, the creator of Linux, Git is designed to be fast, flexible, and efficient. It allows multiple developers to work on a project simultaneously, keeps track of changes made by each contributor, and ensures a smooth collaboration process. Real-World Applications of Git:<ol><li style="color: rgb(36, 36, 36)">Version Control in Software Development: Explanation: In software development, multiple developers often work on the same project concurrently. Git keeps a historical record of changes, allowing developers to track modifications, understand the evolution of the codebase, and revert to previous versions if needed. </li><li style="color: rgb(36, 36, 36)">Collaborative Development: Explanation: Teams of developers collaborate on projects, contributing code changes. Git facilitates collaboration by providing a platform for sharing and integrating these changes. It prevents conflicts, ensures version consistency, and allows developers to work on different aspects of a project simultaneously. </li><li style="color: rgb(36, 36, 36)">Branching and Merging: Explanation: Git enables developers to create branches for distinct features, bug fixes, or experiments. This branching system allows for isolated development. Once a feature is complete, the changes from the branch can be merged back into the main codebase, maintaining project stability. </li><li style="color: rgb(36, 36, 36)">Code Review : Explanation: Before merging code into the main branch, it is essential to review the changes. Git supports a pull request or merge request process, providing a platform for team members to review, discuss, and approve proposed changes before integration. </li><li style="color: rgb(36, 36, 36)">Rollback and Revert: Explanation: Inevitably, issues or bugs may be introduced. Git’s ability to roll back to previous versions or revert specific changes is crucial for maintaining a stable codebase. This helps in quickly addressing and fixing issues without disrupting ongoing development. </li><li style="color: rgb(36, 36, 36)">Remote Collaboration: Explanation: With teams distributed across different locations, Git’s distributed nature allows developers to work locally and synchronize changes with a remote repository. Platforms like GitHub and GitLab serve as centralized hubs for remote collaboration, enabling seamless sharing and tracking of code changes. </li><li style="color: rgb(36, 36, 36)">Continuous Integration and Deployment (CI/CD): Explanation: Git integrates with CI/CD pipelines, automating processes such as testing and deployment. Whenever changes are pushed to a repository, automated workflows are triggered, ensuring that code is continuously tested and deployed, leading to faster and more reliable software delivery. </li><li style="color: rgb(36, 36, 36)">Documentation Management: Explanation: Git isn’t limited to code; it can also version control documentation. This ensures that updates, additions, or deletions in project documentation are tracked, offering a clear history of changes over time. </li><li style="color: rgb(36, 36, 36)">Open Source Collaboration: Explanation: Git plays a central role in open-source projects. Contributors can fork a repository, make changes, and propose them through pull requests. Maintainers can review, discuss, and merge these contributions, fostering a collaborative environment in the open-source community. Certainly! Here’s a list of 20 Git commands along with examples: 1. <code>git init</code>: Initialize a new Git repository.<pre><code>git init</code></pre>2. <code>git clone</code>: Clone a repository into a new directory.<pre><code>git clone https://github.com/example/repo.git</code></pre>3. <code>git add</code>: Add changes in your working directory to the staging area.<pre><code>git add file.txt</code></pre>4. <code>git status</code>: Show the status of changes as untracked, modified, or staged.<pre><code>git status</code></pre>5. <code>git commit</code>: Record changes from the staging area to the repository.<pre><code>git commit -m “Commit message”</code></pre>6. <code>git pull</code>: Fetch changes from a remote repository and merge them into the current branch.<pre><code>git pull origin master</code></pre>7. <code>git push</code>: Push changes to a remote repository.<pre><code>git push origin master</code></pre>8. <code>git branch</code>: List, create, or delete branches.<pre><code>git branch
git branch new-feature</code></pre>9. <code>git checkout</code>: Switch branches or restore working tree files.<pre><code>git checkout feature-branch</code></pre>10. <code>git merge</code>: Combine changes from different branches.<pre><code>git merge feature-branch</code></pre>11. <code>git log</code>: Show the commit logs.<pre><code>git log</code></pre>12. <code>git diff</code>: Show changes between commits, commit and working tree, etc.<pre><code>git diff</code></pre>13. <code>git reset</code>: Reset current HEAD to a specified state.<pre><code>git reset — hard HEAD^</code></pre>14. <code>git remote</code>: Manage set of tracked repositories.<pre><code>git remote -v</code></pre>15. <code>git fetch</code>: Download objects and refs from another repository.<pre><code>git fetch origin</code></pre>16. <code>git stash</code>: Stash changes in a dirty working directory away.<pre><code>git stash</code></pre>17. <code>git tag</code>: Create, list, delete or verify a tag object.<pre><code>git tag -a v1.0 -m “Version 1.0”</code></pre>18. <code>git log</code>: Show the commit logs.<pre><code>git log</code></pre>19. <code>git cherry-pick</code>: Apply changes introduced by some existing commits.<pre><code>git cherry-pick &lt;commit-hash&gt;</code></pre>20. <code>git remote add</code>: Add a remote repository.<pre><code>git remote add upstream https://github.com/upstream/repo.git</code></pre></li></ol>

Top 20 Git Commands With Examples

<h3 class="editor-heading-h3" dir="ltr">let's check what the React team have been doing and what will be provided in react 19.</h3>Following the exciting announcements at React Conf 2024, it's clear that the future of React is bright. The new features and improvements unveiled are set to be released soon and will be generally available to all. Among these advancements, the React Compiler stands out as a game-changer. In a move that underscores React's commitment to the open-source community, the React Compiler will be open source, allowing developers worldwide to contribute to its evolution. <h3 class="editor-heading-h3" dir="ltr">New/Extended Features in React 19</h3><blockquote class="editor-quote" dir="ltr">Some of them already stable and available on Next.js</blockquote> 1. React CompilerThe React Compiler is a significant feature in React 19. It takes your React code and converts it into regular JavaScript. This process can potentially double the performance of your application. The need for a compiler arises from the challenges with memoization and multiple re-renders. Traditionally, React uses a process called bundling to transform the JSX code into optimized JavaScript files for the browser. The new compiler takes this concept a step further. It analyzes your code at a deeper level, understanding the structure and dependencies between components. React operates on a core principle: re-rendering of UI triggered by changes in application state. This allows us to describe the desired end state of the UI, rather than implicitly writing step-by-step instructions on how to manipulate the DOM. However, this can sometimes lead to excessive re-renders. To prevent this, we had to intentionally optimize our components using memoization techniques. Memoization in React is a performance optimization technique that involves storing and reusing the results of expensive computations or component output based on the input parameters. The React Compiler aims to simplify this process by automatically handling memoization and re-rendering. It allows compiled React code to automatically render only the right parts of the UI when the state changes. This removes the need of <code spellcheck="false" style="white-space: pre-wrap;">useMemo</code>, <code spellcheck="false" style="white-space: pre-wrap;">useCallback</code>, and <code spellcheck="false" style="white-space: pre-wrap;">memo</code>. (If you follow the rules of react) 2. Server ComponentsServer Components in React 19 allow components to be processed on the server before delivering the page to users. This results in faster page loading and better SEO. It's a significant improvement as it reduces the amount of JavaScript that needs to be sent to the client, improving performance, particularly on slower networks. 3. ActionsActions in React 19 simplify the management of data and interactions within web pages. They provide a pending state that starts at the beginning of a request and automatically resets when the final state update is committed. This allows you to keep the current UI responsive and interactive while the data is changing. 4. Document MetadataDocument Metadata in React 19 allowing us to accomplish more with less code. It provides a way to manage the metadata of a document, such as the title, meta tags, and other head elements. This is particularly useful for SEO and user experience, as it allows to dynamically change the metadata based on the application state. 5. Asset LoadingAsset Loading in React 19 enables assets to load in the background. This improves both the application's load time and the user experience. It's a significant improvement as it allows for better control over how and when assets are loaded, which can have a big impact on performance. 6. Web ComponentsWeb Components in React 19 introduce improved compatibility with the Web Components standard. This allows for more flexible and compatible frontend development. It's a significant improvement as it allows us to use custom elements, shadow DOM, and HTML templates. 7. Enhanced/New HooksIntroduces four new hooks: <code spellcheck="false" style="white-space: pre-wrap;">useOptimistic</code>, <code spellcheck="false" style="white-space: pre-wrap;">useFormStatus</code>, <code spellcheck="false" style="white-space: pre-wrap;">useFormState</code>, and <code spellcheck="false" style="white-space: pre-wrap;">use</code>. 1. useOptimisticThe <code spellcheck="false" style="white-space: pre-wrap;">useOptimistic</code> hook allows you to update the UI optimistically before receiving confirmation from the server². This provides a seamless user experience by ensuring that users don't have to wait for feedback. It's particularly useful in scenarios where you want to give immediate feedback to the user, even before the server has responded. 2. useFormStatusThe <code spellcheck="false" style="white-space: pre-wrap;">useFormStatus</code> hook manages the status of form fields, handling validation logic and submission state. It gives you status information of the last form submission. This simplifies form management by providing a centralized mechanism to monitor and modify the status of form fields. 3. useFormStateThe <code spellcheck="false" style="white-space: pre-wrap;">useFormState</code> hook serves as a manager for form input states. It offers a centralized mechanism to monitor and modify their values efficiently. It allows you to update state based on the outcome of form actions. This hook requires two arguments:<ul class="editor-list-ul"><li value="1" class="editor-listitem"><code spellcheck="false" style="white-space: pre-wrap;">fn</code>: This parameter represents the function to execute when the form is submitted or a button is pressed. Upon invocation, this function receives the previous state of the form (initially the <code spellcheck="false" style="white-space: pre-wrap;">initialState</code> that you pass, subsequently its previous return value) as its initial argument, followed by the arguments that a form action normally receives.</li><li value="2" class="editor-listitem"><code spellcheck="false" style="white-space: pre-wrap;">initialState</code>: This argument denotes the initial state value desired for the form. It can be any serializable value. Once the action is initially invoked, this parameter becomes irrelevant.</li></ul>4. useThe <code spellcheck="false" style="white-space: pre-wrap;">use</code> hook is a versatile React Hook designed to fetch and utilize the value of a resource, such as a Promise or context, within your components or custom hooks. What sets <code spellcheck="false" style="white-space: pre-wrap;">use</code> apart from other React Hooks is its unique ability to be invoked within loops and conditional statements, such as if blocks. However, it still adheres to the standard requirement that the function utilizing <code spellcheck="false" style="white-space: pre-wrap;">use</code> must be either a Component or another Hook.Check out: React19 beta API docsIn conclusion This will be an overall improvement not just on user experience but also for developers.The React Compiler stands out as a game-changer. It takes your React code and converts it into optimized JavaScript, improving performance. This is a significant step forward as it not only enhances the performance but also simplifies the development process by automatically handling memoization and re-rendering. This means that we can focus more on building great user experiences rather than worrying about performance optimization.On my opinion the use hook is another powerful addition that is set to revolutionize how we write and manage state in our React applications. The use hook provides a more flexible and efficient way to fetch and utilize the value of a resource, such as a Promise or context, within your components or custom hooks. What sets it apart from other React Hooks is its unique ability to be invoked within loops and conditional statements, such as if blocks. This brings a new level of dynamism and control to state management in React.

React 19 new features and improvements

<img src="https://utfs.io/f/ZYRRinLHP5x8zlfYkohAh0E2N3IyjWJ5GY9KwHBUbLOqAvuX" alt="URL image">Seen the above before? Probably… and probably quite a lot…There are millions of articles explaining how to fix the error above, but what exactly is this “Cross-Origin Resource Sharing” (CORS) thing, and why does it even exist?Why???Let's begin by first answering the question of why through a scenario and how it’d play out at different points in time.Imagine this: you log into&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>, which is your banking service. After logging in, a “session cookie” is stored in your browser. (Session cookies basically tell the server behind&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>&nbsp;that your browser is now logged into your account). All future requests to&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>&nbsp;will now contain this cookie, and it can respond properly knowing you are logged in. Ok, so now you decide to check your mailbox. You see a suspicious email, and of course, you decide to click the link inside which sends you to&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">attack.com</code>. Next, this website sends a request to&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>&nbsp;to get your banking details. Keep in mind that&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>&nbsp;still thinks you are logged in because of that session cookie… that cookie is stored on your browser. For the servers behind&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>, it just looks like you requested your banking details normally, so it sends them back. Now&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">attack.com</code>&nbsp;has access to these and stores them elsewhere maliciously.People realized this was bad, so browsers adopted an SOP (Same-Origin Policy) where if your browser notices that you are trying to make requests to&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>&nbsp;from anywhere other than&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>&nbsp;they will be blocked. Now, this is a key thing to realize —&nbsp;this is a browser-based policy.&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>&nbsp;really has no way to tell where a request comes from, so it can’t protect much against attacks like CSRF. The browser you are using steps in and basically says that if you seem to be trying to request details for an origin (scheme + domain name + port, https//foo.com:4000, http//bar.org:3000, etc… Basically the URL), it will only send those requests for same origins.Now, this was great and all, but it was incredibly limiting. I mean, public APIs wouldn’t work at all. You couldn’t request data from them unless you used some sort of proxy solution.CSRFHere’s the thing: servers can sorta tell where a request came from. There is the “Origin” header, which requests should have, showcasing what origin made a request. For instance, in the above example, the request would look something like this.<pre class="editor-code" spellcheck="false">Request to -----&gt; bank.com { Headers: { Origin: http://attack.com } }</pre><code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>&nbsp;in theory, should be checking this to make sure it only responds to requests where the origin makes sense. And it usually does, so SOP seems kinda limiting. This is where CORS comes in.CORSWhen a web application from&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">example.com</code>&nbsp;attempts to request resources from&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>, the browser automatically includes an&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">Origin</code>&nbsp;header in the request, indicating where the request originates from (<code spellcheck="false" style="white-space: pre-wrap;">example.com</code>). Here's the crucial part: Instead of outright blocking such cross-origin requests under the SOP,&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>'s server can inspect this&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">Origin</code>&nbsp;header and decide whether to allow or deny the request based on its own CORS policy.If&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">bank.com</code>&nbsp;considers&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">example.com</code>&nbsp;trustworthy or the resource being requested is meant to be publicly accessible, it can respond with specific CORS headers, such as&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">Access-Control-Allow-Origin</code>, indicating which origins are permitted to access the resource. This header might be set to&nbsp;<a href="http://example.com" class="editor-link"><code spellcheck="false" style="white-space: pre-wrap;">http://example.com</code></a>, explicitly allowing this origin, or&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">*</code>&nbsp;for public resources that any origin can access.Of course, the browser facilitates all this. If any of it is wrong, you’ll get that nasty error.Now… what if the request doesn’t have the Origin header? What if it has a bunch of other headers and doesn’t use one of the basic HTTP methods?In these situations, the handling of CORS becomes a bit more intricate as it is no longer a “simple request”. This is where the concept of "preflight" requests in CORS comes into play.PreflightFor certain types of requests that could potentially modify data on the server—those that use HTTP methods like PUT, DELETE, or use headers that are not automatically included in every request—browsers will first send a "preflight" request before making the actual request. This preflight request is an HTTP OPTIONS request, and its purpose is to check with the server whether the actual request is safe to send.The preflight request includes headers that describe the HTTP method and headers of the actual request. Here’s what happens next:<ol class="editor-list-ol"><li value="1" class="editor-listitem" style="text-align: start;">Server Response: If the server supports the CORS policy and the actual request, it responds to the preflight request with headers indicating what methods and headers are allowed. This might include headers like&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">Access-Control-Allow-Methods</code>&nbsp;and&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">Access-Control-Allow-Headers</code>.</li><li value="2" class="editor-listitem" style="text-align: start;">Browser Decision: Based on the server's response to the preflight request, the browser decides whether to proceed with the actual request. If the server's response indicates that the request is allowed, the browser sends it; if not, the browser blocks the request, and you'll see an error related to CORS.</li></ol>ConclusionNow, hopefully, you understand a little bit more about CORS. I think the most important thing to realize is this is all browser policy, and your server must be coded to comply with it. It is in place to keep you safe. If you are using Chrome, you shouldn’t worry as much about clicking the wrong links (of course, you still should worry a little :D). However, this isn’t a foolproof policy. If you use some 3rd party browser that doesn’t comply with standards, all this would be thrown away. That is why one must remain careful with what software they use!

CORS Finally Explained — Simply

<h1 class="editor-heading-h1" dir="ltr" style="text-align: start;">Describing the issue</h1>Occasionally, mistakes happen when performing a reset operation, such as a hard reset using the command&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git reset --hard &lt;commit hash&gt;</code>. In such cases, if we accidentally reset a commit and then view the commit history using the&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">log</code>&nbsp;command, we will not be able to see the reset commit. So now we are stuck in a situation where we have lost our codes.Even git log command won’t do us any good<pre class="editor-code" spellcheck="false">git log - oneline - all - graph</pre>And if we try it we won’t be able to see it. <h1 class="editor-heading-h1" dir="ltr" style="text-align: start;">What happens when we hard reset a commit?</h1>When you perform a hard reset on a commit in Git, it has the following effects:<ol class="editor-list-ol"><li value="1" class="editor-listitem">Moving the branch pointer: The branch pointer (e.g.,&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">HEAD</code>&nbsp;or a specific branch name) is moved to point to the specified commit, effectively discarding any commits that came after it. This means that the branch is reset to the specified commit, and all subsequent commits are no longer reachable from the branch.</li><li value="2" class="editor-listitem">Discarding changes: By default, a hard reset not only moves the branch pointer but also updates the working directory and staging area (index) to match the state of the specified commit. This means that any changes made in the subsequent commits will be discarded, and the working directory will reflect the exact state of the commit you are resetting to.</li><li value="3" class="editor-listitem">Irreversible operation: Unlike a soft reset, which retains the changes from the commits being reset and places them in the staging area, a hard reset permanently discards those changes. It effectively rewrites the commit history.</li></ol>But don’t worry the thing is after resetting a commit Git won’t remove it completely but rather keep it in its repository for a while and if it wasn’t used then it purges(garbage collects it) it for good. And to recover we can get help from reflog command. <h1 class="editor-heading-h1" dir="ltr" style="text-align: start;">What is reflog command?</h1><img src="https://miro.medium.com/v2/resize:fit:700/1*Z7yv9Y0wligkOKvCqB2P8Q.png" alt=""> The&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git reflog</code>&nbsp;command in Git is used to display the reference log, which records the changes in the Git references (such as branch heads or the&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">HEAD</code>&nbsp;pointer) over time. It provides a detailed history of the movements of these references, including commits, branch creations, checkouts, merges, and other operations. The reference log is local to your repository and is not shared with remote repositories.When you run&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git reflog</code>&nbsp;without any arguments, it displays a list of recent operations and their corresponding reference updates. Each entry in the reflog includes a commit hash, the action performed, and the reference affected. The most recent operations are listed at the top.The&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git reflog</code>&nbsp;command is particularly useful in scenarios where you need to recover lost commits or branches. By examining the reflog, you can identify the commit hash of a lost or detached branch and restore it.Here are a few common use cases for&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git reflog</code>:<ol class="editor-list-ol"><li value="1" class="editor-listitem">Recovering lost commits: If you accidentally delete a branch or reset it to a previous commit, you can use&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git reflog</code>&nbsp;to find the commit hash of the lost branch and recreate it.</li><li value="2" class="editor-listitem">Recovering from accidental branch deletion: If you mistakenly delete a branch, the reflog can help you identify the commit hash of the deleted branch. You can then recreate the branch using the commit hash.</li><li value="3" class="editor-listitem">Recovering from accidental reset: If you accidentally perform a&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git reset</code>&nbsp;operation and lose commits, the reflog allows you to find the commit hash of the previous state and restore it.</li><li value="4" class="editor-listitem">Reviewing repository history: The reflog provides a detailed history of all reference changes, allowing you to review and understand the sequence of operations performed on your repository.</li></ol>It’s important to note that the reflog retains this historical information for a limited time, based on the Git configuration. By default, it keeps the information for 90 days. However, you can configure the retention period if needed. <h1 class="editor-heading-h1" dir="ltr" style="text-align: start;">How to use reflog to recover our lost commit?</h1>To recover a lost commit using&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git reflog</code>, you can follow these steps:<ol class="editor-list-ol"><li value="1" class="editor-listitem">Run the command&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git reflog</code>&nbsp;to display the reference log, which shows a history of reference updates and operations.</li><li value="2" class="editor-listitem">Look for the commit you want to recover in the reflog. Each entry in the reflog includes a commit hash and a description of the operation performed.</li><li value="3" class="editor-listitem">Identify the commit hash of the lost commit in the reflog. It should be listed along with the action that caused it to be lost (such as a reset or branch deletion).</li><li value="4" class="editor-listitem">Once you have identified the commit hash, create a new branch to recover the lost commit. You can do this by running&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git branch &lt;branch-name&gt; &lt;commit-hash&gt;</code>, replacing&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">&lt;branch-name&gt;</code>&nbsp;with a suitable name for the new branch and&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">&lt;commit-hash&gt;</code>&nbsp;with the hash of the lost commit.</li><li value="5" class="editor-listitem">Verify that the lost commit has been successfully recovered by running&nbsp;<code spellcheck="false" style="white-space: pre-wrap;">git log</code>&nbsp;and checking if the new branch contains the desired commit.</li></ol>By creating a new branch pointing to the lost commit, you effectively restore access to the lost commit and any subsequent commits that were previously inaccessible.

Blogs

Top 20 Git Commands With Examples

React 19 new features and improvements

CORS Finally Explained — Simply

Recovering a lost commit in Git

Deploy static website on S3 bucket and configure CloudFront distribution