Three steps helped me a lot to not mess up with GIT anymore:
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 to 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 other names to hold your code, you can make more branches and change its names to whatever suits you more.
Not only do these terms go to the same place, but all operations in git are related to a commit (hash) somehow. 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 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 still can recover files that went to the stage area. The garbage collector will erase 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 that you can recover that change because it is still inside the object history even if there aren't any branches linked to it. The only thing you can do to make it impossible to retrieve is when you prune the commits.
So even your changed code is lame, commit it to a local branch. It can save your day or even your job.
3 - When in doubt, use a temporary branch.
Have you ever had the fear 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 branch called "temp" and brings all commits and local changes you did. If the branch "temp" already exists, it erases everything already there, making it perfect for temporary usage.
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 beside 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 merging in a temporary branch, you kept your code and the remote code intact.
If you made a mistake, you can always switch back to your original branch and create the temporary branch again.
And if you made it right, you can use THE SAME command to switch back into your original branch. Let me show you how this works.
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!
And here they are! The three steps to never have headaches with git again! Practice these steps with temporary branches and never be afraid of using git anymore.