Wild Wonder S1 E4— Advanced GIT

Advanced spells for a GIT Wizard 🧙🪄

Comfy with the previous articles E1, E2, E3? Want to flex on your fellow wizards in training? These will impress and might save the day for someone!

Git Reset

Within GIT you have 3 major sections:

• Your working directory. This is your local machine’s IDE and all the files you’re working with.
• The staging area. Created when you use git add to add your files ready for a commit.
• A commit history. Being the state of files you have committed.

We talked about the command git reset before in the staging section. But did you know it can do much more than clearing out files in staging? If you make a bad commit this could save you. Use git log to get a list of your previous commits and their IDs you can then use git reset <commit-ID>. This will take you back to the commit without deleting any of the files you were working on. These files will be moved to staged and ready for any fixing needed.

It will also move the head of the branch back to that commit SHA (the commit ID) you gave in the command. This is git reset working in mixed mode which it will do as standard. You can add a --hard flag to the command git reset --hard <commit-ID>. This will take you back to the SHA of the commit you provided but will remove the files you were working on.

Just GIT resetting my repo BRB!

Also as a slight WARNING!!!

You’ll not, I repeat NOT!! be able to recover the files when using the hard flag!!!

So make sure to not do this on any pushed commit on the remote repo as other coders could be reliant on another change you made. It can then also make messy merges in the future!

Git Revert

Revert is what you need to use when you want to undo a commit that won’t hurt others working on the same remote repo! Use git log to get the ID of the bad commit you have pushed. Then run git revert <commit-ID> this will remove the file like git reset — hard <commit-ID> but the revert will live in the commit history!

So if you do another git log you will see a new commit that shows the commit you reverted to. Pushing this will help reduce any issues for other workers on the repo.

So remember kids!git reset for local but once pushed switch to git revert instead. You can also add a message to your revert by adding a -m flag and your message after the revert command. It looks like git revert <commit-ID> -m “revert message”

Amend

Amend is a great flag you can use to help add and change your previous commit. It’s especially useful if you forgot to add a file you were working on or fix a commit message. Use git commit --amend -m “new commit message” to change the message of your last commit.

You can see this change by doing a git log to see your commits and messages. If you want to add another file you forgot to the latest commit you can do git add <your-file> and then git commit --amend --no-edit. This will add your file and not change the latest commit message.

Git Stash

Stash is great if you need to save your current work for later without committing it. It’s easy to use by entering the git stash command any un-committed changes get tucked into the stash. When you want to get it back out you run git stash pop and it’ll pop it right back to where it was.

You can also name your stashes by using git stash save <stash-name>. You can also peek into your stashes with git stash list to see each stash with its index and name if provided. The git stash pop command will use the most recent stashed item and put it back. But you can use git stash apply <index> to bring back your chosen stash that may be under some more recent stashes.

A secret little readme stash never hurt anyone

It’s a very useful tool to use but try to keep it simple. It can lead to merge conflicts if two stashes are affecting the same line of code. Don’t worry if you end up with many stashes you’d like to get removed, the git stash clear command will remove them all. You can also remove the latest one with git stash drop.

Git Rebase

Rebase is an alternative to a merge which some developers will argue for and against, depending on the situation. It is a more destructive action and is usually only used when working on your branch, not the main branch. It re-writes the GIT history and makes it look like the main was always the feature branch you rebased to.

It can help keep a tidier GIT history but it does this by re-writing it and can be confusing for others. If you were to rebase your feature branch with the latest changes from the main branch you start with git checkout <feature-branch>. This ensures you’re on your feature branch and not “main”. Then for the real magic use git rebase main.

This brings the main branch updates into your code and makes it look like you only made your new feature branch from the latest main commit.

Squash

Squash is a great addition to a rebase. Squashing targets your commits and lets you clean them up ready for when you want to merge your feature branch. This helps create a clean and more consistent commit history.

It allows you to still make your end-of-day half-finished commits before a weekend, without having everyone else reading through it at the pull request. You can squash everything into a single commit message. Or you can refine it into smaller more incremental commits it’s your choice. Running git rebase main --interactive pulls up a document in your IDE or CLI to customise your rebase.

VIM interfaces are not my friend most days…

You will see a list of your commits with their IDs and the commit messages with the command pick at the front of them. This is the default and will keep the commit as it is with no changes made. You can change your later commits to squash and this will push them into the previous commit message.

If you leave your first commit as pick then change the rest to squash will move all your commit messages into one big message. Once you save and close this file another will open showing the commit messages. This is where you can change them as needed, or close this file and it will default and move all messages into one commit message.

This was the final section of the course I followed and the conclusion of my first learning and development day. If you missed Episode 1, Episode 2 or Episode 3 I would encourage you to go give them a read as well! I hope you have enjoyed and are following for my next L&D day where I dive into NEXT js 13!

Thank you for reading my first Wild Wonder! 💛