Few GIT commands, that you must know

Andy K
4 min readMar 29, 2023

--

Does this even need any introduction?

Photo by Yancy Min on Unsplash

git rebase

This is how it looks like

Creating a feature branch require a root commit inside primary branch, from which the new branch will be created.

But still is it possible to commit (e.g. via pull requests) to main branch, and after few commits your branch will not contain things that were integrated in the same time.

Simple example: Terraform. During some IaC development, let it be a module, few times I had to perform code validation and plan, using:

terraform validate

terraform plan

The result of the plan command showed that some resources will be destroyed, in case of applying given plan. But i didn’t delete anything.

What happened?

New resources were merged into main branch, and they were not present in my branch — I’ve created my branch sooner. After rebase — everything was OK. No destroys, only additions, just like it should be.

git checkout -b <new_branch>

This one allows to create a new branch from the point you currently are, and immediately switch to it. Just a cool timesaver :)

git push — force-with-lease

I’ve discovered this one just recently, and immidiately adopted it into my workflow.

Every time you do a rebase of your branch and then try to push it to remote — error. Usual solution is to perform commit with --force flag, which is not a good idea by the way.

I’d say that in 99% times when you’re using this flag — everything is fine
(as long as you know what are you doing), but still — this 1% left here
is for a human mistakes.

For example overwrite of whole main branch with not-updated feature branch. That sounds really bad…

So what is the difference?

--force-with-lease allows to protect remote branch from changes during push if local history is not divergent from remote.

In other words — using this option, you will not overwrite somebody-else’s changes that were introduced in the meantime — trying to do so, will throw an error.

git push origin — delete

Just to be exact — it is git push origin --delete <name_of_the_branch>

It allows you to delete branch from remote origin, but keep it locally.

If you don’t want to accidentally perform push to this branch again, it’s also worth to execute git branch --unset-upstream afterwards.

<name_of_the_branch> should be replaced with the name of branch you want to delete.

git rm — cached

If you want to add a file to .gitignore, but it is currently being tracked by git, you will notice, that git will continue to track the file. To overcome this situation, you must delete the file from tracking.

git rm --cached <name_of_the_file>

After performing this command, the file will be staged with status deleted, but keep in mind, that it will not mean physical deletion of the file. After performing a commit — the file will be still there, but no longer tracked by git.

git merge — squash

To keep linear history in primary branch, I really like to use “squash commit”, which causes all commits from feature branch being “packed” into single commit that is being added to primary branch.

This is how it looks like…

Any drawbacks?

Well — as always, this is not ideal solution. Creating one commit means that every part of the new feature will be packed. Because of that, detailed information about given feature implementation will be lost.

If anytime in the future, you’ll need to track down who introduced some bug — it is possible that result of this search will not be accurate.

From Github pull-request view

git pull — ff-only

“ff” stands for “fast-forward”

Allows to pull from remote origin only if local history is not divergent from remote. It’s my default pulling method :)

Hey!

Thank you for being here, and for your time! I hope you’ve learned something useful from here. Feel free to comment!

Thanks a million!

Andy :)

--

--

Andy K

DevOps in work. Linux and Cloud enthusiast everywhere.