Workflow of Git & Github

Git and GitHub are used to track changes to a file, which is why they're often used by developers on projects that involve multiple contributors. Git allows you to track versions of a project, with the ability to roll back in case of problems. It's fairly easy to set up since it's like a web interface for your repository on GitHub.

Imagine you are running an application and at a point it gets breaks and you're thinking wish I could go back in time and check the code, wish I could go back in time and see my project how looked back before or last year
in that codebase where my application was running like saving the history of the project's overall flowchart till now or taking picture of it, Here comes the Git & GitHub

The Branches:
Branches are the like the root node of the tree internally it's an acyclic graph (Acyclic graph directory – An acyclic graph is a graph with no cycle and allows to share of subdirectories and files.)

Branches in Git are incredibly lightweight as well. They are simply pointers to a specific commit nothing more: (branch early, branch often)

Because there is no storage/memory overhead with making many branches, it's easier to logically divide up your work than have big beefy branches.

When we start mixing branches and commits, we will see how these two features combine. For now though, just remember that a branch essentially says "I want to include the work of this commit and all parent commits."

The most important thing about the branches is always to create a new branch if you are working on an open source project or contributing to another's project never go with the main/master branch the reason is that our code is not finalized yet there might be a bug to committing to the main branch can create a ruckus which should not be affected in user's result. So always go for the newly created branch.

Now for creating the new branch:
git branch feature(random branch name)

git checkout feature now all the commits you will make will be added through the feature branch which is the head.

Git Rebasing:
The combining work between branches is rebasing*.* Rebasing essentially takes a set of commits, "copies" them, and plops them down somewhere else. While this sounds confusing, the advantage of rebasing is that it can be used to make a nice linear sequence of commits. The commit log/history of the repository will be a lot cleaner if only rebasing is allowed.

Git HEAD:
The head is the symbolic name for the currently checked-out commit -- it's essentially what commit you're working on top of. HEAD always points to the most recent commit which is reflected in the working tree. Most git commands which make changes to the working tree will start by changing HEAD.

Normally HEAD points to a branch name. When you commit, the status of <branchname> is altered and this change is visible through HEAD.

Detaching HEAD:

Detaching HEAD just means attaching it to a commit instead of a branch. This is what it looks like beforehand.

To maintain the new commit that has been merged in the main repo and the forked one we need to fetch/sync our forked repo
git fetch --all --prune
that's how we fetch all the changes and now we can set the main branch of the origin to the main branch of the upstream
git reset --hard upstream/main

Imagine 100s of people sharing the code in one particular file or sort of project just as we do in open source projects. How can we do that?
Git & GitHub allow us to do that where we can see which person made what changes in particular files in Repository

Github it's a platform which provides hoisting of our git repositories.

Git CLI:
git init
to start with the git files.
These files are hidden and if you want to see the hidden files just put

git -a

this command will show the hidden files in macOS and Linux

git status

Here's The git status that tells that hey here are all the changes which have not been added to the history of your project.
git add .

(.) dot means everything in the directory which has not been added yet so that it tells to add all the uncommit files. else if you can go with the just git add and you can also go with git add filename.txt, git add and then we can see the file will be added and in the next step, we need to put

git commit -m
where -m refers to providing a message you want to add with the commit which is Mandatory & important so there should be transparency on what changes we have made.

Now you can maintain the history of the project. This is enough for you to get started with the git

to add something to the files use:
vim filename.txt

To see the updated file:
cat filename.txt

Now we know how to add a commit and check the status what if we've done the mistake of adding the wrong here we go with the~

git restore staged --filename
and check
git status

Again here uncommitted file will be removed from the stage.
The main part is where we can see the history of the changes we have made till now.

git log
and to delete the file
rm -rf filename.txt

In the real world, you won't have a nice commit tree visualization next to your terminal, so you'll have to use git log to see hashes.

if you want to remove or reset whatever file we can use git reset and the committed hashes
git reset
This reverses changes by moving a branch reference backwards in time to an older commit. In this sense you can think of it as "rewriting history;"
git reset
This will move a branch backward as if the commit had never been made in the first place.

Furthermore, hashes are usually a lot longer in the real Git world as well. For instance, the hash of the commit that introduced the above is fed2da64c0efc5293610bdd892f82a58e8cbc5d8.

The upside is that Git is smart about (commit) hashes. It only requires you to specify enough characters of the hash until it uniquely identifies the commit. So I can type fed2 instead of the long (hash) string above.

if you want to remove or reset the file we can use git reset and the committed hash:
git reset fed2da64c0efc5293610bdd892f82a58e8cbc5d8

What if we add the files but we don't want to commit them as of now neither we want to lose them so we can send these files backstage or put them on hold so whenever we want we can call these files and commit changes
we can do this by
git stash

Now calling all the files backstage to the front stage
git stash pop

Git Cloning and Workspace setup :
git clone "repo-url"
and for adding the repo in your workspace
git remote add upstream Now the git branch is added from the forked repo

Here you go with the command for adding the repo
git remote add origin

Note: From where you have forked the repo and adding this on your workspace from the forked repo :
git remote add upstream
git remote -v.
Git remote add origin

Git CLI way to Sync forked repository with origin repository:
git fetch upstream
git merge upstream/main

After the merge, we can add files and commit & push

PlaywithGit This link might help to understand everything from Beginner to advance about Git.

Conclusion:
This is enough for any beginner(just like me 🤓) to get things started. Try to apply this and get stuck with it because that's how we learn right? get your hands dirty on this, Start contributing to open-source projects and Keep Learning.
And please correct me in the comment, if I'm wrong somewhere and missed something.