Git Ready To Branch Out
In order for us to truly understand the power of git, we must first learn the objective of the program. Git is a Distributed Version Control System (DVCS). Imagine a time machine for our code - that's essentially what a version control system is, offering a magical portal to travel through the history of our project, saving us from the dreaded 'What did I change?' moment.
While there are other tools that we can leverage to handle version control for us, we are going to focus on Git. Unlike a centralized version control systems (VCS) where a single central repository stores the entire history of the project, Git is distributed. We can work with a complete copy of the repository, including its full history, on our local machine. This allows us to work offline and makes collaboration more flexible.
Git is designed with speed and efficiency in mind to allow us to create branches and merge code. We can create branches to work on new features or bug fixes independently without interrupting the main codebase. As changes are completed we can merge the new branch with a production or development branch. This makes it suitable for projects of all sized.
Because it is an open-source project, it is free to use and is supported by a large community of developers that contribute to the success and maintenance. Honestly it is the only version control system that I have ever used.
Downloading && Installing Git
If we don't have Git installed locally, the most critical step is to install Git on our machine before we can start using it for version control. We can typically download and install Git from the official Git website or use a package manager specific to our operating system (e.g., apt for Ubuntu, Homebrew for macOS). Once Git is installed, we can proceed with initializing a Git repository in our project directory and start utilizing Git for version control.
Important Tip When Installing Git For The First Time.
Avoid the default setting of using VIM as our text editor of choice unless we explicitly want it. The reason for this is that its keyboard shortcuts may not always align with what we're accustomed to, leading to issues in understanding and executing commands. If we mess this up it is ok there is a fix. We can change our default text editor to something such as VS Code quite easily by using a terminal command also.
If you are unfortunately stuck within VIM without knowledge of escape then you will have to use your keyboard to evade its grasp. First press Esc, and then type : wq and press enter. You could also learn to love the keyboard shortcuts its truly a user preference.
git config --global core.editor "code --wait"
Click here for a list of many other popular editors.
As our repository grows in size and complexity, more and more commits are created. In addition to this, branches are created and merged or pushed to the remote repository. Naturally, if we wish to visualize this data within a terminal, we might want to leverage a tool. Git, in fact, facilitates this for us when we execute a command that extends the height of our terminal. The tool it leverages is called less, which is a terminal pager program. It enables us to view, search, and navigate entire documents page by page within the terminal. In order to leave this program from the terminal we must execute a keyboard shortcut. Simply press the letter q on your keyboard to quit.
Git Commands
There are more than a dozen git commands available to us. We do not need to memorize them all. In fact we will only use a handful on the regular, but it is worth knowing about them all and how to utilize them.
Init vs. Clone
If we are just starting a project, one of the very first steps we should take as a developer is to enable git tracking by typing git init into the terminal. There will be other times when we are working on an existing project and can use git clone <url> to download the remote repository to our local machine.
| Command | Description |
git init | Initialize a new Git repository in the current directory. |
git clone <url> | Clones a repository from a specified URL, creating a local copy on your machine. |
Logs, Diffs, and Branches
Each of these commands will open up less to paginate the data returned if it is extends the length of the screen.
We can look through a crystal ball through time using the git log command. Depending on how many commits that our repository has it could be dozens of pages worth of commits. We can actually do something really neat by copying the long hash number provided with a commit! The git log command in Git is used to display the commit history of a repository. It provides a detailed log of commits, showing information such as commit hashes, authors, dates, and commit messages. Here's a comprehensive overview of how git log works:
By default, without any arguments it returns information about each commit including the commit hash (unique id), the author's name and email, and the date, time of the commit, along with the commit message. If we want we can provide an option of --graph to view a graphical representation of the commit history, showing branch and merge relationships. You can also provide the --oneline option to condense each commit into a single line making it easier to scan through commits.
If we need to see the difference between the current state of our working directory and the last commit then we would type git diff into the terminal without any arguments. This is useful to explore the changes we might be proposing when considering our next commit message. You can narrow it down by providing an optional filename such as git diff index.html to view changes made to our local version of index.html vs the remote version. We can also use the option --staged to see the differences made between our local files and the staged files. We can also pass in two file name arguments to view a difference between two files. By default Git displays differences using the Unified Diff format, which shows the added lines with a + symbol and removed lines with a - symbol. Overall, git diff is a powerful tool for inspecting changes in our repository, allowing us to understand precisely what modifications have been made to our files and how they differ from various points in the project's history.
Filtering Commits: git log supports various options for filtering the commit history. For example:
git log -<n>: Show only the last<n>commits.git log --since=<date>: Show commits more recent than the specified date.git log --author=<name>: Show commits authored by the specified name.git log <branch>: Show commits reachable from the specified branch.
Custom Formatting: We can customize the output format of
git logusing the--prettyoption. For example,git log --pretty=format:"%h - %an, %ar : %s"will display each commit's abbreviated hash, author name, relative commit date, and commit message.Viewing File Changes: Adding the
--statflag togit logwill show a summary of changes for each commit, including the number of insertions and deletions per file.Navigating History: We can navigate through the commit history using various keyboard shortcuts:
j: Move down one commit.k: Move up one commit.Enter: View detailed information about the selected commit.q: Quit the log view.
Overall, git log is a powerful tool for exploring the history of a Git repository, providing valuable insights into the evolution of a project over time.
Often times we want to see a list of all branches that we have available to us. This can be done using the git branch command. Typing this into the terminal without any arguments will emit a list of all branches on our local machine. The currently checked out branch is typically indicated with an asterisk. Very often times we have more branches remotely than locally. Sometimes we have branches locally but not remotely. In order to view all branches, we can use the option of -a or --all with the command such as: git branch -a or git branch --all. This provides us with a list of all branches within a repository. By using other options like -r or --remote we can view only the remote branches. We can create new branches by simply adding the branch name after branch such as: git branch testing. We can also rename branches using the -m option and also providing the old name and a new name like this: git branch -m testing testing2. We can delete branches using the -d <branch-name> option. For example, if we wanted to remove the branched we renamed to testing2 we could type git branch -d testing2 into the terminal.
To recap we went over the git branch command and the options that we can provide and the syntax we can follow to do different things.
| Option | Description |
git branch <none> | Displays a history of commits in the repository, including commit messages, authors, and timestamps. |
git branch -a or --all | Displays both local and remote branches. |
git branch -r or --remote | Displays remote branches. |
git branch <branch-name> | Creates a new local branch with specified title |
git branch -m <old-branch-name> <new-branch-name> | We can even rename branches using this syntax. |
git branch -d <branch-name> or -D for Force | We can remove branches from the repository using the -d or -D option. |
Here is a recap of the git diff command and the options that we can provide.
| Option | Description |
git diff <none> | When we run git diff without any arguments, Git shows us the differences between the current state of our working directory (i.e., the changes we've made since the last commit) and the staging area (where changes are prepared for the next commit). |
git diff --staged | We can also use git diff --staged or git diff --cached to see the differences between the files in the staging area and the last commit. These are the changes that are currently staged for the next commit. |
git diff <filename.ext> | We can narrow down the output of git diff to specific files or directories by providing their paths as arguments. For instance, git diff file.txt will show the changes made to file.txt. |
git diff <commit1> <commit2> | By specifying commit hashes, branch names, or tags, we can compare different commits using git diff. For example, git diff commit1 commit2 will display the differences between two commits. |
| Unified Diff Format | By default, Git displays differences using the Unified Diff format, which shows the added lines with a + symbol and removed lines with a - symbol. |
To be continued...