Git, set, and Bash!
Elevate your programming life with GIT CI/CD
I'm a programmer, I control your life, but I don't have one of my own.
The term "source control management" refers to Git-SCM.
You can quickly test, develop, and deploy your code in an automated manner by utilising GIT. As a result, you can write and test code more quickly and guarantee that it's always current and error-free. GIT can also make it simple to roll back changes if something goes wrong and maintain track of changes made to your codebase. Last but not least, GIT will assist you in making sure that the code you deploy is consistent with a high calibre and that any fresh modifications you make are tested properly before deployment. This is comparable to the multiverse theory, which contends that there are parallel universes for every outcome of a certain event. Similar to how Git's branching feature enables developers to examine a project from several perspectives, the multiverse theory postulates that every scenario that could result in an event has been investigated in a different world.
Therefore, Git will be helpful for you whether you develop code that only you will view or work in a team.
How was Git Started:
NOTE: Bitkeeper VCS was adopted by the programmers who were contributing to the development of Linux in 2002. However, Bitkeeper asked them to pay the Linux Development team a sizable amount of money in 2005 after removing their free tier. Following this, Linux creator Linus Torvalds started developing his version control system before creating Git, a free Centralized Version Control System. And everybody began to use Git.
It's a very well-liked tool for organising concurrent work and managing projects across teams and individuals. Without a doubt, being able to utilise Git is one of the most crucial abilities for any developer nowadays, and it will look fantastic on your CV!
Git Bash
1. Setup
We may utilise our system terminals to access the command-line interface, which is how Git is generally used. However, we must first confirm that Git is set up on our PCs. Git Downloads
To get things set up on your computer, click the download link for the appropriate operating system and then proceed through the installation tutorial.
Start your terminal after installation and enter the following command to see if Git is prepared to be used on your computer:
git --version
The Git version that is installed on your computer should be returned if everything went according to plan.
Configuring Your Name & Email
Run the following commands in your terminal to log in as Git:
git config --global user.name "Username"
git config --global user.email "your@email.com"
Your name and email address should be substituted for the values inside the quotes.
2. Repositories
It's crucial to be familiar with the word "repository" when using Git. A project that is tracked via Git is hosted in a repository.
There are two primary categories of Git repositories:
Local Repository - You can work on the local version of your project in a separate repository that is stored on your computer.
Remote repository - often kept on a server located far from your isolated local machine. The area where you can share your project code, view other people's code and incorporate it into your local version of the project, as well as publish your modifications to the remote repository, is very helpful when working in teams.
3. Initialization
Use your terminal programme to find the project's main folder, then execute the following command to start a new repository and begin monitoring your project with Git:
git init
A hidden .git directory for your project will be created by this command, which is where Git maintains all of the internal tracking information for the current repository.
ls -a
4. Staging and committing code
The act of committing involves adding the changes "officially" to the Git repository.
Commits in Git can be thought of as checkpoints, or snapshots of your project as it is right now. In a commit, we essentially preserve the most recent version of our code. The commit history allows us to create as many commits as necessary and navigate back and forth between them to view the various iterations of our project's code. This makes it possible for us to effectively manage our progress and monitor the project's advancement.
As we develop our project, commits are often created at logical points, usually after including certain contents, features, or updates (like new functionalities or bug fixes, for example).
NOTE: We must first put our code within the staging area before we can commit it.
4.1. Status
To check the repository's status while inside the project folder in our terminal, enter the following command:
git status
When using Git, this is a command that is frequently used. It displays information about which files have changed, are being tracked, etc.
Based on the results of the git status command, we can add the untracked project files to the staging area.
If we decide to add our tracked files back to the staging area later, git status will notify us of any changes we made.
4.2. Staging files
We can add our files to the staging area from the project folder using the git add command so that they can be tracked.
With the following command, we can add a specific file to the staging area:
git add file.js
We can perform the following to add multiple files:
git add file.js file2.js file3.js
We may also add all the files contained in the project folder to the staging area rather than having to do so individually:
git add .
By default, this moves the project folder's files and directories to the staging area, where they are prepared for commit and tracking.
4.3. Commits
A commit is a copy of our code that we are storing in the repository's commit history at a specific moment. We are prepared to make a commit once we have used the 'git add' command to add all the files we wish to track to the staging area.
The following command is used to commit the files from the staging area:
git commit -m "Commit message"
The commit message, which is used to distinguish it in the commit history, should be typed inside quotation marks.
A detailed overview of the changes you are committing to the repository should be included in the commit message.
You will see the technical information about the commit written in the terminal after running that command. In essence, you have now effectively committed to your project.
NOTE: You must repeat the steps of adding files to the staging area and then committing them to make a fresh commit. Once more, using the git status tool to identify whether files were updated, staged, or untracked is quite helpful.
4.4. Log
Use the command below to view every commit that was made to our project:
git log
Each commit's data, including the identity of the author, the hash that was generated for it, the time and date it was made, and the commit message we gave, will be displayed in the logs.
You can use the following command to return your project code to a previously committed state:
git checkout <commit-hash>
The actual hash for the particular commit you want to see, which is listed using the git log a command should be substituted for <commit-hash>.
You can use the following command to return to the most recent commit or the most recent version of our project code:
git checkout master
4.5 Revert commit
If you have one specific commit you want to undo just run the command below once you have the hash for the commit you wish to undo:
git revert hash --no-edit
NOTE: Git will not prompt you to submit a commit message if you choose the
--no-editoption.
4.6 Reset commit
You can roll things back to a previous good commit if you have done local commits that you don't like and that haven't been pushed yet. The bad commits will appear to have never occurred. Run the following command once you are aware of the hash for the most recent reliable commit (the one you want to roll back to).
git reset hash
NOTE: If you do a git reset the commits will be removed, but the changes will appear as uncommitted, giving you access to the code. This is the safest option because maybe you wanted some of that code and you can now make changes and new commits that are good. Often though you'll want to undo the commits and threw away the code, which is what git reset --hard does.
4.7. Ignoring files
You can create a file called .gitignore in your main project folder to stop files that you don't want to be tracked or added to the staging area from being tracked.
Each ignored file and folder should start on a new line in the .gitignore file, where you can list all the names of the files and folders that you most definitely do not want to track.
5. Branches
A project commit's particular chronology could be thought of as a branch.
With Git, we can build a lot of these distinct settings (i.e., multiple branches) so that alternate versions of our project code can exist and be followed concurrently.
This enables us to add new features on distinct branches without changing the "official" stable version of our project code, which is often retained on the master branch. These features are experimental, incomplete, and potentially buggy.
When we set up a repository and begin making changes, they are automatically saved to the master branch.
5.1. Creating a new branch
With the following command, a new branch can be produced:
git branch <new-branch-name>
The newly generated branch will serve as a reference to the state of your repository at that time.
NOTE: It makes sense to set up a development branch where you can work on your code's enhancements, experimental new features, and other things. You can merge these new features to the master branch once you've developed and tested them to ensure there are no bugs and that they can be used.
5.2. Changing branches
Using the git checkout command, you can change to a different branch:
git checkout <branch-name>
With that, you change branches to move to a separate discrete timeline of your project.
NOTE: For instance, you might have a separate branch for each feature you are working on in your code. You can commit code changes that only affect the branch you are currently on when you move to it. After that, you can switch to a new branch to work on a different feature without the changes and commits from the earlier branch interfering.
The -b flag can be used to simultaneously generate and change to a new branch:
git checkout -b <new-branch-name>
Use the following command to list the branches for your project:
git branch
Use this command to get back to the master branch:
git checkout master
5.3. Merging branches
When you want to apply the code changes you made in one branch to another branch, you can merge the branches.
For instance, you might want to merge changes to the stable branch of your project (which is typically the default master branch) once you have thoroughly implemented and tested a new feature in your code.
You can use the following command to incorporate modifications made in another branch into your current branch:
git merge <branch-name>
The branch that you want to merge into your current branch would be replaced with <branch-name>.
5.4. Deleting a branch
You can use the git branch command with the -d argument to delete a branch:
git branch -d <branch-name>