This post is one of the Git 101: Conquer the GIT POWER series.

Summary:

1. Everything is a hash
2. Stage and commit changes.
3. When in doubt, use a temporary branch.

Let's discuss these steps one by one.

1 - Everything is a hash

Commit, Branches, Tags, HEAD, Master, Develop. All those things are hashes. Everything will make it clear the moment you incorporate that in your mind.

A commit is a hash that points to a change/creation/deletion of some file inside the repository. A series of commits, one atop one another, is called git history.

Branches are just alias we use to differ a git history from each other.

The last commit change in a branch is called a HEAD. And, guess what? Is a hash too.

A tag is like a branch, but it has a different purpose. While branches can change their commits, a tag is a fixed position. When you create a tag, you create a read-only branch to mark a significant point in the commit history, for example, a version or a substantial change.

Master and Develop are branch names created by convention. They usually contain the production and development code. But if you want another branch name to hold your production/development code, you can name it to whatever suits you. I add the branches homolog, preprod, and release into the project to stretch the deployment steps to simpler units.

Not only do these terms go to the same place, but all operations in git are related to a commit (hash). For example, look at the most used commands with that perspective in mind:

• Git checkout: Change the current commit history to another branch or commit.
• Git pull: Bring the remote commits to your local branch.
• Git push: Send your local commits to the remote branch.

I couldn't emphasize enough how much easier it will be to learn the following steps if you assimilate that knowledge. If you didn't understand, please try again because that will guide you for the rest of your journey in learning how git works.

2: Stage and commit changes.

You just realized that git stores everything In hashes, right? But how are they formed? The creation of the first hash occurs when you put a file in a stage state. That hash is not the commit hash but a key identifying the file you staged.

Staging a file is simply preparing the change to be committed. While you don't change the working copy, you can recover files that went to the stage area. The garbage collector will erase it eventually but will do after months. Thus, you have plenty of time to retrieve the change.

A wise developer doesn't just stage his files. He commits them to a temporary local branch (more on that in the next topic).

When you commit, you make sure you can recover that change because it is still inside the object history even if there aren't any branches linked.

So even if your changed code is lame, commit it to a local branch. It can save you many hours.

3 - When in doubt, use a temporary branch.

Have you ever feared that if you pull your branch, it will flood it with conflicts? Or worse, that YOUR changes will break the production code? Or had to roll back a commit because you couldn't understand that branch anymore?

The following command fixes these problems, removes all fear, and eases the pain when merging branches.

git checkout -B temp

That's it. This command creates a local "temp" branch and brings all commits from your real branch. If the branch "temp" already exists, it erases everything inside it, making a safe place to make git operations without repercussions.

Note that you can use any name; it doesn't need to be "temp." You can name it "temporary", "working", "test", "test2", "banana" whatever.

When you create a local branch without a remote, it only exists in your repository. No one can see or interact with this branch besides you.

It is like safe heaven. You can do whatever you want without limits, and if something goes wrong, you can safely switch back to a "real" branch, use the same command and start again.

This command shines when executing merging operations. When you fail to merge and need to restart from scratch is easy to reset your mistakes from your real branch to try again.

And if you made it right, you will use the same checkout -B command to switch back into your original branch.

For example, let's say you have a branch named feat/new-form in your repository. You have to merge your code with develop. What do you do?

git checkout feat/new-form
git checkout -B temp

Then you start your merge with develop. Did you mess up? Alright, then reset the branch with the original branch content.

git reset --hard feat/new-form

And like magic, you are at the start point again. But now you did it right and successfully merged the two branches. What to do now?

git checkout -B feat/new-form

This command switches back to your original branch and brings the successful merge too. That way, you will never mess up your branches again!