How I Use Git for Version Control
Tutorial - Git for Version Control with Code Summary
Intro
Have you ever found yourself appending numerous "final" prefixes or suffixes to project files, whether they're code or documents destined for someone else's eyes? I can certainly relate. When coding, there were times when I hesitated to make changes, fearing I might disturb a perfectly working model (as the joke goes, "never touch anything if it works"). To tell the true, for a long time I deliberately avoided delving into the world of Git. It was a bit like putting off the inevitable, leaving Git on the back burner for my future projects. To be completely honest, my initial motivation to embrace Git wasn't fueled by a desperate need for "version controlling." Instead, it was driven by the necessity to showcase my code in public repositories, demonstrating my capabilities through side projects. In the past, my solution was to create backup files that I could revert to if things went awry. However, actively using Git eradicated all these concerns. What's more, Git's beauty lies in the fact that I need to provide comments for each "commit," helping me pinpoint exactly when I may need to revert to.
But that's not all. While I will focus on version control in this post, Git excels in synchronizing my settings across different machines. Working on various operating systems, including MacOS, Windows, and a couple of Linux distributions, used to be a headache in terms of initial settings. However, Git has been a lifesaver, effortlessly synchronizing my configurations, regardless of the operating system I'm working on.
Admittedly, I know there are many tutorials. Yet, I found most of them focus on using Git within large team projects, which can be daunting for individuals without a robust background in IT. So, in this post, I aim to share how someone can kickstart Git on their local machine, using it for version control in their solo projects. The format of this post is narrative, so if you're eager to dive into the code examples, feel free to jump to the code example section.
Body
Let’s get started
Getting started with Git is a breeze. Once you've confirmed Git is installed (you can check using git --version), navigate to the folder where you want Git to track changes. The command git init does the trick, prompting Git to keep tabs on all alterations within the folder. This command generates a bunch of files in a hidden .git folder (for those unfamiliar with UNIX-based file systems, files or folders starting with a dot . are hidden). Congratulations, your folder is now under Git's watchful eye.
The next logical step, post-initializing a Git repository, is to start adding files for tracking. The command git add <file> (or git add . to add all files in the current folder) stages the changes, preparing them for a commit. The terms 'stage' and 'commit' initially puzzled me, but there's no need to fret. Just think of them as letting Git know which files you've modified, and a commit will essentially log those changes. While many tutorials delve into Git's commitment to tracking changes through hashing and fancy techniques, don't be swayed. If you stage and commit (using the 'add' and 'commit' commands), you're good to go. It's worth noting that a 'commit' serves as a snapshot of the changes made, offering insight into the purpose and context of each alteration. Developing the habit of crafting clear and concise commit messages is a valuable practice that pays off in the long run. Your changes are saved, ready for you to revisit later.
.gitignore
In the journey of managing your project with Git, you may encounter situations where not all files are meant to be tracked. It could be due to the sensitivity of certain information or perhaps the sheer size of some files. Here, the .gitignore file comes into the paly, serving as a handy tool to guide Git on what to pay attention to.
Imagine you've got a file named secret.txt harboring sensitive information or a bunch of log files with the ubiquitous .log extension cluttering your workspace. The .gitignore file allows you to gracefully sidestep these, maintaining focus on what truly matters. To implement this, simply create a file named .gitignore in the same directory where your .git folder resides.
Open the .gitignore file and start specifying the files or patterns you wish to ignore. . A line in the .gitignore file might look like this:
gitignoreCopy code
# Ignore sensitive information
secret.txt
# Ignore all .log files
*.log
# Ignore a specific folder
my_folder/
# Ignore all files in a specific folder
images/*
Once you've finished your .gitignore file, save it, and let Git know about the changes by committing it—git add .gitignore and git commit -m "Add .gitignore file".
Also, there might be files you no longer want to track—maybe due to sensitivity or evolving project needs. Tostop tracking a file without deleting it, use git rm --cached <file>. For instance, if you've decided that config.conf should no longer be tracked, run: git rm --cached config.conf Once done, update your .gitignore file to ensure Git continues to ignore the file.
This way, your project adapts to changing needs, keeping unwanted files out of Git's version control scope.
branch out
As your project unfolds, the need to create branches in Git becomes pivotal. Branches provide a way to work on new features or fixes without disrupting the main codebase. The commands git branch <branch_name> and git checkout <branch_name> are your allies in this process. The former crafts a new branch, while the latter gracefully shifts you to that newly created branch.
I find the metaphor of branches in a tree quite fitting—just like the branches in a tree allow for new growth while keeping the main trunk untouched, Git branches offer a similar advantage. This allows me to experiment and innovate, knowing that the main codebase remains unaffected. Unlike real tree branches, however, Git branches have the potential to become the main stem, carrying forward the changes made.
Once you've made changes on your branch, it's time to reintegrate them into the main codebase. The command git merge seamlessly combines the changes from your branch back into the main branch. During merging, you may encounter merge conflicts, but there's no need to worry. Git provides clear instructions to address these issues—just read the errors carefully and follow the instructions.
One thing I highly recommend is managing branches in an organized form. Later on, these branches can serve as your project history, offering a valuable record of how the project has evolved.
.
Time machine
What if you find yourself in a situation where your code suddenly stops working, bombarded by a multitude of errors that appear confusing and difficult to decipher? No worries—Git's powerful ability to revert or reset to a previous commit is a key feature designed to handle such challenging scenarios. Begin by navigating to the log page with the command git log. Once you locate the point in time where things took a wrong turn, you have two main commands at your disposal: git revert <Hash> and git reset <Hash>.
Using git revert allows you to cancel out a specific commit, essentially undoing the changes introduced at that point. On the other hand, git reset takes a more drastic approach by rewinding your project to the chosen commit, discarding all subsequent commits. The choice between the two depends on the nature of your mistake and the desired outcome.
An essential tip in this process is the value of expressive commit comments. The more descriptive your comments are, the more you'll thank yourself when navigating back to exact points in your project's history.
Here, below are extracted commend lines.
# Check Git version and confirm installation
git --version
# Initialize a Git repository in the desired folder
git init
# Add files for tracking
git add <file> # or git add . to add all files in the current folder
# Commit changes with a clear and concise message
git commit -m "Your commit message"
# Create a .gitignore file to specify files or patterns to ignore
# Open .gitignore and add patterns
git add .gitignore
git commit -m "Add .gitignore file"
# Stop tracking a file without deleting it
git rm --cached <file>
# Create a new branch
git branch <branch_name>
# Switch to the newly created branch
git checkout <branch_name>
# Merge changes from a branch back into the main branch
git merge <branch_name>
# Navigate to the log page
git log
# Revert changes from a specific commit
git revert <Hash>
# Reset the project to a specific commit, discarding subsequent commits
git reset <Hash>
## Git log example ##
## commit abc12345 ---> this is <Hash>
## Author: Tony Lee <[email protected]>
## Date: Mon DEC 25 00:00:00 2023 +0000
## (comit comment) "Merry Christmas Committ"
And there you have it! This journey takes you through a full cycle of version controlling with Git. We've covered the initiation of a project, tracking changes, creating branches for development, handling mistakes, and even navigating through your project's history with Git. The next step in your Git mastery is exploring remote repositories. Fortunately, major Git hosting platforms guide you step by step, providing easy-to-follow commands that make the process straightforward. So, take a deep breath, because with Git, you're not just controlling versions; you're actively shaping your project's journey.