Git is the most popular version control system or source control. (Version control systems or source control are software that enable developers to track and manage their code). As a version control system, it records the changes made by developers in its database called Repository. It helps developers track their project history, make changes, foster collaboration between and among developers and teams. Git enables us to keep track of our project history, see who made changes there, track when the changes were made, find out why it was made and still enable us to revert unpleasant changes made in our repositories.
Git is a distributed VCS as opposed to centralized subversion and Microsoft Team Foundation server where all team members connect to a central server to share copies of their codes and the changes made. If the server goes off, teams cannot connect but wait until the server is up. In Git VCS, it is distributed such that collaborating team members can have a copy of the project with its history on their machine or systems. Should the central server go down, teams can still harmonize and work together pending when the server comes up.
Git is fit for DevOps because it's free, open-source, agile and scalable, easily accessible, fosters team collaboration, easy to use as it can be used in the command line, code editor or IDEs and in GUI for all operating systems including Ios and android with just a little limitation on tool availability such as Gitkraken, Tortoise Git, Sourcetree, etc.
SETTING UP MY GIT
I specified my configuration settings through: my name, Email, default editor and how git should handle my line endings with reference to the below listed levels: System - The settings here apply to all users. Global - The settings here apply to all repositories of the current user. Local - The settings here apply to the current repository in the local folder.
On the command line, I started with configuring my name with this command:
- git config --global user.name "Name Name" (I used double quotes in my name because there is a space in between my first and last name to signify that they are the same command).
- git config --global user.email married3timex@gmail.com
- git config --global core.editor "code --wait" (the reason I used wait is to tell the terminal to wait until we close a new vs code instance). All these 3 configuration settings are stored in a text file in my default editor which is vs-code. To open the vs code, I used the last command.
- git config --global -e (next setting is how git would handle the line endings. Since I am using Linux, my ending of the line is indicated by \n which is called line feed. As opposed to windows which has but \n - line feed and \r - carriage return) To get \n as my line ending, I had to configure **core.autocrlf
- git config --global core.autocrlf input** (reference git config documentation to get help)
CREATING MY FIRST PROJECT DIRECTORY
On the command line, I created a directory and named is “git_project, inside it, I created another directory to contain mini files and named it mini_git
Since it is my first file and I wish to add to a new project directory, I have to initialize a new empty repository using this command git init
To open the directory .git where git stores all my project history, I used open .git from the GUI, from there, I can see our projects. (warning! If you touch or remove this project history, all projects will be lost. Which is why git made it hidden).
BASIC GIT WORKFLOW
Basic git workflow is I could do on a daily basis when using git. I have my project directory and git repository which is hidden somewhere in our local system. Everyday, as part of working on my project, I modify one or more tasks. When my project reaches the stage I would want to record, I would commit those changes into my repository. Commit is like taking a snapshot of my project. In git, There is a special area or a special intermediary that is not featured in most other VCS called the staging area or index. When developers are done making changes, they add the modified files to the staging area, review the changes and if everything is good, they make then commit. That is to say that the staging area allows us to review our snapshot before committing it into the repository.
GIT COMMIT contains:
- ID
- Message
- Date and Time
- Complete snapshot of our project.
Note: the first time a new project is initialized in a new directory, git will not automatically track the files no matter the number of files in that directory. To ascertain that those files are not initialized into the git repo, use the git status command. You will see that on our branch master, that there is no commit yet and the files I created are untracked. The files created are not in the staging area and that is why they are indicated by red colour.
To add files to the staging area, I used the command git add if they are multiple files that I may want to add all together, I can use the same come as thus git add (remember to add spaces in between the files).
Another way to add files is to use add all the files with the same extension together with this command git add .txt or git add .py etc.
Another way is to use git add . **(this adds all files in the entire directory but you have to be careful when using this command to be sure I am not adding heavy files which will occupy so much space in my repo or add unwanted files.
Use git status to check if the files were added to the staging area. If it is true, the file colours will change to green.
FILE MODIFICATION
To modify a file or make changes to it, I used the echo command as thus echo >> file1.txt eg echo My first git project >> file1.txt The file has been successfully modified. When I use git status to check, the file I just modified is in red colour below the files I initially staged. Ran the git add command again to add the modified file back to the staging area.
COMMITTING OUR SNAPSHOT TO THE REPOSITORY
Command used was git commit -m “a short description of our project. ” Note that -m is for message and it's usually used when the description of my project is short but when the description of my project is detailed, I would use only git commit. This opens up my default editor which is vs code when the editor opens. The first line where the cursor blinks is where I can write a short description, usually not more than 80 characters. Then on the preceding line, I can add a long description of any length.
COMMIT BEST PRACTICES
- Commit should neither be too big nor too small.
- It is not ideal to make a commit every time a file is updated because it will keep multiple files of the same name clustered in my repository.
- It is advisable to always commit my code as it is being written instead of piling them but each commit should represent a new cycle or change. For example, if while fixing a bug, and found a typo, I should not commit these two changes in one commit. Rather, two separate commits, one for the type and one for the bug fix.
SKIPPING THE STAGING PART OF THE COMMIT
In case I feel okay with my project and would not want to always stage it before committing it, after I must have modified my file with echo(eg echo test >> file1.txt), I can then commit it with git commit -a -m “ description” (-a signifies all modified files, -m for message. You can actually combine -a and -m together) git commit -am “description”
REMOVING FILES
Files are removed when it does not have any need anymore and instead of leaving it there with the unused code, for security reasons, it should be remove with the linux rm command Eg rm file1.txt . note that the file will not entirely be removed because it was earlier pushed to the index stage. Check it up using git status and use git ls-files to ascertain this. Everytime changes are made, there is need to stage the changes and it could be done through git add and it will be entirely removed.
RENAME A COMMAND
The basic mv command in linux to rename file mv file2.txt main.txt and when this is executed, I used git add on each of the file to effect the changes. git add file2.txt and also execute git add main.txt and used ls l-a to list the files in that directory. To see if the changes are affected, git status.
IGNORING FILES
Log file and binary files are files that git created as a result of compiling our code. They are not sharable. Adding these files will just occupy our repo space without adding values. I created a directory with mkdir log and used echo command to write to the log file e.g. echo hello > dev.log and when I run git status, it will report “untracked directory”. I will not be adding this new directory to the staging area because I would not want git to track the logs. To prevent this, I created a file called .gitignore . This file is just an extension with no name and it is in the root of my git project. I wrote to the extension using echo logs/ .gitignore and open the log file in the IDE using code .gitignore
Once the gitignore file opens in IDE, I gave it a heading called logs and add all the log files eg *.log (to add all the log files) (main.log) save the changes and go back into the terminal.
Use git add to add the changes made. git add .gitignore and git commit -m "New changes"
To view my HISTORY
I used git log command to view all thatI have done in my repo so far, starting from last to first. Each commit has a unique ID of 40 characters. Next is (HEAD -> master) master is the main line of work in git. Head is a reference to the current branch. This is how I would know what branch I am currently working on. On each commit, I can see the author, the data and time the commit was made and the email address. To quit the log page press q.
The log command has a few interesting options.
git log --oneline - this shows a short summary of the commit.
git log --oneline --reverse - reverses the order of listing.
VIEWING COMMIT
We use this to view the changes or what we have done in a commit. We use the git show note that I can just type 3 of the id number instead of typing all provided the numbers are not the same. Since head is usually on the first commit in the list, I could use HEAD~1 or 3 or 2 (just count the line of the commit list and use the number) eg git show HEAD~4
Inspiration credit: Mosh Hamedani on youtube