Top 10 git commands - ovokpus/MLOps-Learn GitHub Wiki

Git is a version control system for managing and tracking changes in code. In previous labs, you learned how to use commits, branches, and other tools to manage workflows. Developers also use other tools in Git and some are more commonly used and apply to a wider range of scenarios than others.

In this lab, you'll work on a subjective list of the top 10 Git commands. These commands will cover a wide range of use cases and with them, you'll be equipped to efficiently manage workflows like an expert. To give you the most benefit, this lab won't cover some of the most basic or common commands, such as clone, push, pull and merge. While those are certainly among the most used and useful commands, they're common enough you probably won't have any issues remembering them.

Working with git stash, pop and blame

Clone the Repository:

git clone https://github.com/cloudacademy/example-git-repo.git
cd example-git-repo

# Confirm that your codebase currently has no modified files:

git status

# Make a change to one of your tracked files:
echo "new line" >> index.html
git status

# Now, stash those changes:

echo "new line" >> index.html
git status

This output confirms that your changes are stashed. A git status command will show that there are currently no modified files:

Similarly, the git stash list command will show any stashed changes:

Restore your stashed changes:

git stash pop

As you can see, your index.html file has been restored to its modified state. Among other reasons, stash and pop are useful tools if you want the ability to make sweeping changes to a codebase while preserving the state of some of your changes.

Next, you'll work with git blame. Try the git blame command for the README.MD file:

git blame README.MD

The output from a git blame command will show each line of a file as a row. From left to right, each row will include:

A commit ID The name of the committer The timestamp of the change made The content of the line Developers use this command, among other reasons, if they need to know who made a certain change or how long ago the change was made.

Working with git diff, reset, checkout, and branch

As you've learned in previous labs, the branch command allows you to view, create and manage Git branches. You've also learned about the checkout command, which allows you to perform several functions including checking out branches and reverting modified files to unmodified ones.

Similarly, the reset command is useful when you need to revert a branch to a previous commit. All of these commands are useful and common enough to make it to the top 10 list for this Lab. One more command that qualifies is the diff command, which in its most basic form allows you to view the differences in tracked files between commits. In this lab step, you'll practice all of these commands.

View the difference between your current state and your last commit:

git diff

As you can see, the diff command outputs a per-file log of any tracked changes since your last commit. Notice the green "new line" text matching the change you made in the last Lab Step.

One use of the checkout command is restoring modified files to a previous state. Restore the modified index.html file:

git checkout -- index.html
git status

As you can see, the modification you made in the last step has been reverted, because the command you ran reverted index.html to its state during the last commit. This is only one of several uses for the command, however. As with any git command, you can run git checkout --help for a complete guide on how to use this command.

Recall that you can also use checkout to switch branches:

git branch new_branch
git checkout new_branch

Similarly, you could use the git checkout -b {some_branch} command to both create a new branch and switch to it. Finally, make a bad commit to your current branch:

rm -rf ./*
git add --all
git commit -m "No worries, I totally meant to do this"

The first command removes everything in your directory. As you've learned from previous labs, the second and third commands add your changes to a staging area and commit them. An ls command will confirm your project is now empty. Since you probably didn't mean to wipe your project out, use the reset command to remove the last commit:

git reset --hard HEAD~1
ls

Working with git log, show and tag

In past labs, you've used the git log command heavily. it's one of the most invaluable commands in your repertoire. Two more you may not be familiar with are show and tag.

The show command can show various types of objects in Git, the default being the details for the last commit. When you use the show command for a specific commit you can see its commit details similar to the log command in addition to its changed content similar to a diff command, making git show an excellent option for quickly gathering information about a commit.

The tag command allows you to create a tag, which is a Git object that points to a commit. Tags are useful for easy tracking of versions of your codebase and are usually used for marked version releases (like v1.0.0).

In this lab step, you'll work with these three commands.

git log

As you know from previous Labs, the log command outputs a list of commits, including the author and time of the commit plus any branches that are currently pointed at it. Execute the show command:

git show

By default, the show command shows output similar to git log, but with only the most recent commit included. It also shows any content changes included in that commit, similar to the diff function. You can also include a commit ID as part of the command to see details about a specific commit.

For example, the command git show ae05432ea07eaf8e2d5232b6a40345f1bb33c9ac will show commit details and content changes for the commit with the id ae05432ea07eaf8e2d5232b6a40345f1bb33c9ac.

Add a tag to your commit:

git tag 0.1.0
git log --oneline

As you can see, git tag will apply a tag to your current commit. Similar to how branches are objects that point to specific commits, tags also point to a commit. However, tags can be thought of as branches that never change.

Unlike branches, which will point to a new commit any time a commit is made while checked out to that branch, a tag will always point to the same commit unless intentionally modified, making tags excellent at tracking codebase versions.

To reinforce how tags work, make a new commit:

touch new_file
git add new_file
git commit -m "add new file"
git log --oneline

Notice that while new_branch points to the new commit as expected, the tag 0.1.0 still points to the previous commit, meaning version 0.1.0 of your application will always be the same version.

One more note about tags is that similar to branches, you can specify tags when doing things like checking out, pushing and pulling. The benefit to doing so is that you know you're managing a specific version of the codebase.