DEV Community: Marius Ibsen

Git reflog: Restore Version Control History

Marius Ibsen — Fri, 02 Sep 2022 11:33:42 +0000

Did you know we can use Git reference logs to restore Git commit history(?) Often we developers experience challenges when working with Git. We can accidentally force-push commits to the remote main branch, complete a rebase that went bad, delete a branch we wanted to keep or hard reset to the wrong commit.

In this post, we will look at git reflog and git reset. We will review some common scenarios on restoring local commits, restoring a deleted branch, and reverting force-pushed changes due to a rebase.

Git reflog

git reflog is a tool that can help us recover almost anything - at least everything we have committed. The tool keeps track of commits that have been created but also discarded ones in a log called the reference log. The reference log is kept on our local computer under the .git directory in a local repository. It contains a list of commits that HEAD has pointed to and keeps track of the entire history of a commit. Besides the reference log for branches, we have a separate reference log for stash.

(Records of the history on a branch will expire after 30 days by default. We can change the expiration days, by running git reflog —expire in our terminal, if we want to keep the history for a longer time.)

It's important to know that reference logs do not track in the remote repository, like pushes, fetches and clones; it is purely local and current to the working environment. Below is two screencaps, the first from Github Codespaces and the second from a local filesystem that initially created all the commits of the main branch in the same repository:

Github Codespaces:

Local computer:

Git log vs reflog

git log is a command that shows a list of commits related to a branch. git reflog is similar to git log but shows a list of snapshots and times when HEAD was changed. reference logs also reference other types such as stash, branches, rebase, merge and tags. A reference is known as refs, and the syntax for accessing these is name@{qualifier}. Running git reflog is the most basic use case and essentially the equivalent of writing git reflog show HEAD. The output will look like this:

=> git reflog

47efaa2 HEAD@{0}: commit: refactor: remove post schema
f243f12 HEAD@{1}: commit: refactor: change author fields
4783ba0 HEAD@{2}: commit: chore: add .env to gitignore
a19d142 HEAD@{3}: commit: chore: update readme
f5ade9a HEAD@{4}: commit: chore: update yarn.lock
854c08f HEAD@{5}: commit (initial): feat: bootstrap sanity studio

Git reset

git reset is a command we can use to move back to a previous commit, discarding or undoing previous changes. We can run git reset --hard <commit_sha> to move our branch back in the commit history.

A hard reset (git reset --hard) will completely destroy any changes and remove them from your local repository.

A soft reset (git reset --soft) will keep your changes, and stage them back automatically.

A mixed reset (git reset --mixed) which is the default, will keep you changes but they will also become unstaged. Even tho it is flexible, you will have to stage the changes manually.

Restore local commits

Scenario

We have made some commits that haven’t been pushed to the remote repository yet. We do a git reset —-hard <commit_sha> to a previous commit, and our local branch is set back to an earlier point and discarded all history after the chosen commit. We then run git log and see that the commits are gone. We cannot pull the changes from the remote repository since we never synced the changes.

How to restore local commits

When running git reflog we can see that our changes still are tracked by the reference log; we even have a separate commit for the hard reset that we did earlier - take a look at commit f243f12 on HEAD@{0}:

f243f12 HEAD@{0}: reset: moving to f243f12
eec6f27 HEAD@{1}: commit: refactor: author should not have image
47efaa2 HEAD@{2}: commit: refactor: remove post schema
f243f12 HEAD@{3}: commit: refactor: change author fields

With this information, we can reset our branch back to the state we discarded by using one of the references in the reflog. We can move our branch to the selected commit by running git reset --hard <commit_sha>:

=> git reset --hard f243f12
=> git reflog

f243f12 HEAD@{0}: reset: moving to eec6f27
f243f12 HEAD@{1}: reset: moving to f243f12
eec6f27 HEAD@{2}: commit: refactor: author should not have image
47efaa2 HEAD@{3}: commit: refactor: remove post schema
f243f12 HEAD@{4}: commit: refactor: change author fields

Restore a deleted branch

We can recover deleted branches using SHA’s in the reference logs.

Scenario

Not uncommonly, we might checkout a new branch in our local environment. We could have a branch called chore/update-packages and commit a change that adds dayjs as a package:

=> git checkout -b chore/add-dayjs-package
=> yarn add dayjs
=> git add .
=> git commit -m 'chore: add dayjs package'

5a75042 HEAD@{0}: commit: chore: add dayjs package

At a later point, we checkout the main branch and deletes the chore/add-dayjs-package branch — maybe we did not need it anymore for some reason:

=> git checkout main

47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main

=> git branch -D chore/add-dayjs-package

Deleted branch chore/add-dayjs-package (was 5a75042)

We will get a confirmation message that git deleted the branch. After a while, we discover that we could need the changes after all, so how do we get them back?

How to restore a deleted branch

We can undo these changes with git reflog and git checkout. If we run git reflog we won't see any references to the deleted branch. We could use the commit SHA provided in the delete message (5a75042) to revert the latest commit on that branch. But if we have lost the message, we need to use the reference log. And if you named your commits well, it should be easy to find the missing commit take a look at commit 5a75042 on HEAD@{1}:

=> git reflog

// deletion of a branch is not logged to the reference log
47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main
5a75042 HEAD@{1}: commit: chore: add dayjs package
47efaa2 HEAD@{2}: moving from main to chore/add-dayjs-package

We can now checkout the deleted commit SHA and create a new branch from that commit running git checkout -b <branch_name>:

=> git checkout 5a75042
=> git checkout -b chore/add-dayjs-package

Revert force-pushed changes

Scenario

We reset our branch using git reset --hard to an earlier commit and run git push - force to override any changes that we otherwise could pull from the remote repository. But at some point, we want those changes back.

=> git reset --hard <commit_sha>
=> git push --force

How to revert force-pushed changes

We can use git reflog and git reset to restore force-pushed changes:

=> git reflog

f243f12 HEAD@{0}: reset: a19d142 to f243f12

By reading the log we can see that the message on HEAD@{0} is reset: a19d142 to f243f12, which means that commit with hash a19d142 was force-pushed by f243f12. That also gives us information about which commit we need to restore, the one with hash a19d142. We can simply do the same procedure as initially to move back to the overriden commit:

git reset --hard a19d142
git push --force

Finally, we force-push the new changes to the remote repository. Always be careful and check that you are on the correct branch before doing a force push. Especially to prevent that production code is not being affected or team member code is not being overwritten.

Thanks for reading! (This article was originally posted on Medium )

Code foh shizzle

React Scroll Hook with Shadows

Marius Ibsen — Fri, 06 May 2022 22:56:10 +0000

Liquid syntax error: Unknown tag 'endraw'

3 Ways of Rendering on The Web

Marius Ibsen — Thu, 29 Apr 2021 08:25:27 +0000

Rendering a website can be done in several ways. A common challenge is when to choose which of the types.

Exploring the options before starting a new project can prevent us from refactoring parts of our code or the entire tech stack. It depends on whether it is crucial to get a good ranking in Google. Or if the content should be more interactive, dynamic, and fade smoothly into the user's view. Or if performance and excellent user experience are more essential for your business goals.

All websites have different needs and having some basic understanding of the rendering on the web will spare you money, time, and frustration.

Concepts and terminology

First, we will go through some basic technical concepts and terminology. Knowing a little about them will help us make even better decisions on our website's rendering options.

These concepts we can divide into two categories: Performance and Rendering.

Performance

Hydration is a technique where JavaScript converts static HTML (returned from the Server) into dynamic and interactive elements in the browser. Also generally referred to as client-side hydration or re-hydration. When hydrating, JavaScript (such as event handlers, listeners, etc.) is linked to the static HTML to make it interactive.
Pre-rendering is a technique where the HTML is rendered A Head of Time at build-time. Pre-rendering is essential for public pages that should get crawled and ranked by search engines. Server-side and Static-side applications use this technique.

Rendering

First Paint (FP) is the first step during rendering after a user navigates to a page. It is the first pixel painted on the screen and in the browser window - everything in the browser window that is visually different from before navigation is processed in the First Paint.
First Contentful Paint (FCP) is the first time the browser renders something to the DOM, such as text, images, or SVG's. During this process, the browser will tell the user that "something is happening."
Time to Interactive (TTI). The browser has rendered the entire website content, at this point, and the user can interact with the elements on the page. That could be pressing a button or clicking in text fields that give some feedback to the user.

Client-Side Rendering (CSR)

Client-side rendered websites do everything "on their own." Such as retrieve data from an API, manage logic, and routing between pages directly in the browser. Every page the visitor visits and its respective URL are being created dynamically.

We can think of rendering on the Client like package delivery, of three packages. Each package will come in a different order and at different times, but you don't know precisely when. You will get the first package, then the second, and at last the third.

Client-side applications typically have a fast FP and FCP. They use hydration which can cause a slow Time to Interactive because the browser needs to "boot up" the JavaScript code, rehydrate, and then load the HTML back into the browser window. The hydration process may vary in time depending on how much JavaScript your application contains.

A slow TTI is not very good for Search Engine Optimization (SEO). Most Client-side applications that need their content crawled and optimized for SEO will have to implement pre-rendering to make it work properly.

Client-side rendering is the default for JavaScript applications. Popular Frontend Frameworks like React, Angular, and Vue use this rendering type.

Pros:

Gives the user quick feedback and a smooth user experience, e.g., a fast First Contentful Paint.
Low server load because all the content is processed and rendered on the client/in the user's browser.
Lower costs than a Server-side rendered application.

Cons:

May cause poor user experience. Potentially, leave the user waiting for content until everything is fully loaded into the browser, resulting in the user leaving the site instead.
Client-side applications make it hard for search engine robots to see the website content, which leads to no or poor indexing.
JavaScript pages will not be visible if JavaScript is disabled in the users' browser.

Server-Side Rendering (SSR)

Server-side rendering (SSR) happens On-demand, also called Just in Time (JIT). Every time the Client makes a request for a page, the Server generates HTML for that request. The HTML is then returned to the Client, wholly rendered, ready to be displayed.

We can think of rendering on the Server like package delivery, much like for Client-side rendering. Instead of getting the packages delivered at different times, you get all at the same time.

Server-side rendering is slower than Static-side rendering because the HTML is generated entirely on each request. But it's faster than a client-side rendered application when returning the entire result to the user.

JavaScript frameworks like Vue and React use hydration to generate interactive code sent from the Server.

Pros:

Suitable for SEO-focused websites.
Gives the user a great user experience by delivering all content on request.

Cons:

It may be expensive. Require setup and managing of servers or server code besides frontend code.
If the Server is down, the website is also down.
It may require a backend/full stack developer in addition to a frontend developer.

Static-Side Rendering

Static rendering happens at build-time. Every page is compiled and rendered as static HTML files Ahead Of Time (AOT). Files generated AOT means that we will produce an HTML file with a separate URL for each file. What is excellent about static websites is that they can be uploaded to a CDN and easily be moved to another source when needed without much work.

We can think of rendering an application statically, much like on the server, just that it is incredibly fast. The packages don't need to be packed beforehand; they're just shipped to you at once.

Statically rendered websites have some significant advantages. They are fast, have better reliability, and improved SEO. Websites generated statically have fast FP, FCP, and TTI.

A few months ago, I wrote an article about what benefits you can draw from having Static Generated Websites. You are welcome to read it: Benefits of Static Websites.

Pros:

Perfect for SEO-focused websites.
Reliable, excellent performance, secure, and scalable
Low costs; it can "live" on a Content Delivery Network (CDN)
Easy to move between hosting providers

Cons:

You are dependent on deploying the entire website in case of changes - like pushing news articles or products for an e-commerce shop.

Let's wrap up

If you ask yourself, "When should one be critical to the choice of rendering type?" this is just relevant when a website contains JavaScript.

CSR may provide a faster response (FCP) to the user. It is more interactive and perfect when content needs to be updated without contacting the Server. On the other hand, suppose you build a website with full JavaScript. In that case, some JavaScript frameworks like React, Vue, or Angular will, in most cases, only render an empty HTML page. Search engine crawlers will see these sites as completely blank until fully rendered.

Many JavaScript frameworks that have become popular in the past years have built-in Static Site Generation (SSG) and Server-side rendering, such as GatsbyJS and NextJS, supporting both SSR and SSG.

SSR and SSG are better for SEO. Both can display page content faster. They give a better user experience, and search engine robots will have it easier to rank your pages. Suppose you have a static website that consists only of HTML. In that case, you do not need to pay attention or worry about SEO optimization or excessive server load at all.

On the latest project I've been working on, we've used a combination of client and static rendering for a couple of years. Doing so is essential because the customer I work for has a website that is both a news page and contains pages where users can see their customer relationship behind some secured pages.

Going entirely for just server-side or just client-side, I would not recommend if you are in the same situation as I described above. Know when to use the different rendering types, and you will make fantastic websites that also give the user a great user experience.

Thank you for reading! Code for shizzle

(This article was originally posted on Medium )