My first post on this blog is about Git, one of the most popular version control systems which is used in many software development projects.
Git is a critical tool for managing and collaborating on software projects, because it allows multiple developers to work on the same codebase* simultaneously while keeping track of changes, versions, and history.
*(In other words, the collection of components such as source code, scripts etc. which make up a software application).
While studying Git, I came across some concepts that are unfamiliar to me such as Version Control Systems, Distributed Version Control Systems and Source Code Management.
Let’s delve into them.
Version Control Systems (VCS): software tools that help track changes to files and code over time. They also cover large binary files and digital assets.
Distributed Version Control Systems (DVCS): A type of VCS that allows every contributor to have all the history of the code repository. Apparently, it is a more decentralised system: for example, contributors can work offline and have access to the full history without relying on a central server.
Source Code Management (SCM): like VCS but only used to manage the source code.
Git is both a DVCS and an SCM!
----------------------------------------------------------------------------------------------------------------------
(Thanks to Kevin Stratvert for the tutorial 'Git and GitHub for Beginners Tutorial', available here).
I proceed to install Git from here and notice that it comes with a terminal called Git Bash. I assume that I can use another terminal that I have on my computer such as Command Prompt rather than Git Bash. Indeed, if I type the command
git config -h
on Command Prompt, it displays the help documentation for Git. Another useful command is
git help config
As suggested by tutorials, before I start using Git, I should specify my name and email address to associate an identity to my commits*.
*(The saving of a set of changes one has made to the project's source code or files; I think of it as a sort of snapshot!).
These are the configurations that I am going to insert in Command Prompt
git config --global user.name "Gian"
git config --global user.email "my.email@example.com"
Then I define a branch, in other words a separate "copy" of the project that might allow me to work on new features, bug fixes, or experiments without affecting the main codebase. I decided to call my branch, “main”.
git config --global init.default branch main
To create a repository (“repo”), I identify a path on my pc where I keep the files that can make up a website. That will be the location for my repository. I first go to the chosen directory
cd C:\Users\etc.
Then
git init
In this way, I created a location where all the source code, project files, and historical changes related to a software project are stored and tracked. I notice that a hidden folder .git is created in my chosen directory; this probably contains necessary components to make Git work (like the heart of the repository).
I believe that if I were collaborating with other developers, this location should have been on a hosting service such as GitHub but I am unsure.
The command git status displays information about the current state of my working directory and the Git repository. In my case, for “C:\Users\etc.”, it displays the name of my branch (“main”) and specifies that there are no commits yet. It also lists the files I put in “C:\Users\etc.” and calls them "Untracked" (in a red font). These are actually not monitored by Git:
- Git does not track changes or history for Untracked files.
- These files do not appear in the commit history, and Git doesn't automatically include them in commits.
Maybe, I need to run it on the same folder, so I repeat
cd C:\Users\etc.
It doesn’t work. Let’s redo
git init
And now it works. But why? Why has changing the terminal forced me to repeat the initialisation process for the specified path? I assumed that specifying the path was enough. Anyway…
I want to Track an Untracked file called file.htm which is in “C:\Users\etc.”, as the status reported.
git add file.htm
I create a .gitignore file out of an empty text file and put it in my chosen directory. Here I can list all the files I want to ignore.
Example:
# ignore all .txt files
*.txt
The first line is a comment describing my intentions. The second one instructs git that I want to ignore all(*) .txt extensions. These files won’t be reported by git status anymore. I save the .gitignore file.
To put files in an environment called staging, a preparatory phase before committing (like holding the pen before writing...), I can use either
1) git add –all
or
2) git add –A
or
3) git add .
1) and 2) are the same: they stage all changes, including new files, modifications, and deletions, both for Tracked and Untracked files
3) It stages changes for Tracked files and new files but does not stage file deletions.
It is still unclear to me the purpose of staging. Couldn’t we have a direct commit without the staging?
Anyway, I am ready to commit*.
*(You can only commit what has been staged unless you force it with git commit -a).
In my experience, I found it unwise to force commit without staging because it might cause tracking issues.
git commit -m “description of what I am doing”
-m (message) is to type the comment. If I use git status, there are no more files shown to commit.
I also found that writing a comment for each commit can be extremely useful because it helps us and the team identify the change and the reason behind it.
----------------------------------------------------------------------------------------------------------------------
If I modify one of the files in my folder and I use the command git status, it will inform me that one file has been modified (the file goes back to the working phase before staging). git diff to display the actual change (red means old, green means new).
git add file.htm -> to stage files.
git restore --staged file.htm -> to remove a file from staging (before commit).
git restore “file.htm” -> to restore a deleted file.
git mv “file.htm” “file2.htm” -> to move (rename) a file. Remember to commit it!
git log -> to display the list of commits made.
git log --oneline -> to display log in one line.
git commit -m “new amended comment…” --amend -> to amend the last commit.
git log -p -> to display the commit history with the actual changes (diffs) introduced in each commit ("q" to quit).
git rebase -i --root -> to open the editor (":x" to quit).
