As part of my personal development, I decided to delve deeper into version control systems and chose the popular Git. For practical application, I selected several simple programming projects to familiarize myself with its core functionalities. Specifically, I implemented a few games and algorithms in C++ and Python.
Why code versioning and why Git? Code versioning is absolutely essential for every programmer, whether working on a small personal project or in a large team. It allows us to track each and every change in the code, gives the ability to roll back in time if anything goes wrong, help develop our code better in collaboration, and last but not the least act as a backup in itself. Git is the most widely used version control system for its flexibility, speed, and broad support.
Why I did learn Git on small projects? Learning Git on small projects has lots of benefits for me. First, it gives space to experiment and make mistakes without serious consequences. We can try out some different commands, play with merging, or switch branches without fear that we will compromise a huge project or cause loss of data. And it is easier to master the basic workflow and understand the principles of Git in smaller projects.
Tools Used:
I have used Cmder and GitHub to work with Git. Cmder is a terminal emulator for Windows that provided me with a comfortable environment for entering Git commands. GitHub is a web-based mechanism for sharing and managing Git repos. That allows me to share my code with others, collaborate on projects, and build an online portfolio. You can learn more about GitHub in my article GitHub: A Beginner’s Guide to Version Control and Collaboration.
The main idea of this article is to get you through the basics of Git with practical examples and show you how to use its basic commands effectively.
Basic Git commands:
git init
Initializes a new Git repository in the current directory (creates a hidden .git directory that contains all the repository information).
git clone <repository_url>
Downloads (clones) an existing repository from a URL (e.g. GitHub) to a local directory. This command creates a copy of the repository including its entire change history.
git status
This command displays information about the current state of the Git repository. In this case, the output says that we are on the “main” branch, which is up-to-date, and that there are no uncommitted changes (“nothing to commit, working tree clean”).
git add <file> / git add
Adds changes to the specified file (or all files in the current directory and subdirectories) to the staging area (which serves as a “storage” for commits).
git commit -m “Commit description”
Saves changes from the staging area to the local repository with a description. This command creates a new commit that contains a snapshot of the current state of the project. The commit message must be visible.
git log
Shows a list of all commits in the repository, including commit hashes, authors, dates, and descriptions.
Git log: shows the complete history, git log –oneline: shows a summary of commits on a single line, and git log –graph: shows a graphical representation of branching.
git branch
Lists all local branches. Git branch <branch_name>: creates a new branch, and
git checkout <branch_name>: switches to the specified branch.
git merge <branch name>
Merges the specified branch into the current branch. This command is used to integrate changes from one branch into another.
git push <remote> <branch>
Sends local commits to a remote repository (e.g. GitHub). The remote repository will be updated with local changes.
git pull <remote> <branch>
Pulls changes from the remote repository and merges them into the local branch. This updates the local repository with the changes from the remote repository.
Reflection
I encountered a challenge while working with Git that pushed me to the next level. One such challenge was having trouble pushing changes to my GitHub repository. My first attempt at a password-based push failed with an error message stating that password authentication support for HTTPS connections had been removed.
I had to find alternative authentication methods, and the best solution was to use a Personal Access Token (PAT). After generating the PAT, I ran into another obstacle – the push failed due to missing permissions to work with the workflow files (.github/workflows/). I solved this problem by excluding the workflow directory from Git using the command git update-index –skip-worktree .github/workflows/.
This experience reminded me of the importance of setting permissions correctly and the need to keep track of updates to the verification procedures on platforms like GitHub. It also strengthened my knowledge of working with Git commands for manipulating the index and how to effectively resolve permission issues in the context of code versioning. I have learnt that it is important to be flexible when solving technical problems. In the future, I can use this knowledge when working on larger projects where collaboration and version control will be important.