Forkify_JS_app | recipe search/shop application using NPM | Frontend Framework library

First, direct (although not all that useful) answers to your direct questions:

1. What is the correct way to revert changes in some files(not all the files previously committed) and push it again?

There isn't one. That is, there is no one single correct way to do this. There are many different correct ways to do this.

1. What is the advantage of using [git reset --soft] if I have to force the push?

If this produces the commit graph you like, that's a way to produce the commit graph you like.

1. After issuing git reset --soft HEAD~1, I could have unstaged the changes> made new changes>commited> forced the push.

This is not a question. It is a statement (and a true one).

1. Why do I always need to force the [push]?

You don't always need to; you do for these cases because you're deliberately asking some other Git repository to throw away some commit(s).

How can I understand the concepts?

The key here is that Git is not really about files—though it stores files—nor about branch names, though it uses branch names. Git is really about commits.

Each commit stores files. In fact, each commit stores a complete snapshot of all files. The files inside these snapshots, however, are in a special, read-only, compressed and de-duplicated format, that only Git itself understands. None of the other software on your system can make any sense of these files. (Note that the de-duplication means that it's OK that every commit stores a copy of every file, because most commits just re-use most of the files from some other commit, so that these multiple copies take almost no extra space.)

It's important to remember that nothing about any commit can ever be changed after the commit is made. In other words, all commits are completely, totally read-only. (This is actually a general property of all internal Git objects and it ties in to their object hash IDs.)

But if commits are read-only, and only Git can read the files, how do we ever use them? We need ordinary files. We need to be able to read them! We need to be able to write to them! So to use Git, we have to take the files out of Git. This is what git checkout—or in Git 2.23 or later, git switch—is for: to locate some particular commit and extract it. Note that Git will find the commit by its hash ID, even if we use a branch name like master. We'll get into this a bit more in a moment.

Before we dive into that, though, we should look at exactly what a commit does for you, because there are two parts to each commit:

• A commit has a full snapshot of all your files. That's its main data: a full copy of every file you told Git to save, at the time you told Git to save it, in the form it had in Git at that time.

• A commit also has metadata, such as the name of the person who made it. Most of this metadata is the stuff you see in git log output: someone's name and email address, a date-and-time-stamp, and a log message, for instance. But one piece of metadata is crucial for Git itself. Each commit stores the raw hash ID of its immediate parent commit, or for a merge commits, its parents (plural).

Most commits have just one parent. If we have a chain of such commits, we can draw them like this: