Git has become one of the most important tools in software development today, and not knowing how to use it is considered a serious gap for any modern programmer. In simple terms, Git is a version control system that records every change in your project. It remembers how your files have changed over time, lets you return to any previous state when needed, and enables several developers to work on the same project simultaneously without getting in each other's way.
Imagine you are working on a large project, and yesterday's code worked perfectly, but after today's changes everything broke. Without Git you would have to remember exactly what changed or manually create backup copies. Git solves this problem completely: every change is recorded, and you can return to a working state with a single command. In this article we will explore the core concepts of Git and the most commonly used commands with practical examples so you can confidently start applying them in real work.
Creating a Repository and Your First Commit
Working with Git begins with creating a repository. A repository is a special folder where your project and its entire change history are stored. To initialize Git inside an existing project folder, run the following command in your terminal. This command creates a hidden directory called .git inside the folder, and this is precisely where all the history and settings of the project are kept, so you should never delete it.
git init
git config user.name "Your Name"
git config user.email "email@example.com"Once the repository is ready, you need to add your files to the Git history. This happens in two stages: first you add the files to a preparation area called staging, then you record them using a commit. A commit is a snapshot of your project's state at a particular moment in time, and each commit is saved with its own description. The following commands add all files and create the first commit in the project history.
git add .
git commit -m "First version of the project"Here the git add . command adds all changed files in the current folder to the staging area, while git commit records them into the history with a message. It is important that the message is clear and meaningful, because in the future you or your team will need to understand the purpose behind each change. Instead of a poor description like "fix", it is far more useful to write "fixed password validation error in the login form".
Checking Status and Viewing History
During your work it is very important to know which files have changed and which of them have not yet been committed. For this you use the git status command. It gives you complete information about files in the staging area, files that have been modified but not yet added, and entirely new files that Git is not yet tracking. Making a habit of running this command frequently will help you always keep the situation under control.
git status
git log --oneline
git diffTo view your project's history you use the git log command. The --oneline flag shows each commit on a single compact line, which helps you quickly scan through a long history of changes. The git diff command in turn shows uncommitted changes line by line, meaning you can see exactly which lines were added or removed since your last commit.
Branches and Merging: Working in Parallel
A branch is one of the most powerful features of Git. A branch lets you split off from the main code and calmly work on a new feature. If your new idea does not work out, you simply delete the branch and the main code remains untouched. If it does work, you merge it back into the main branch. The following example shows how to create a new branch and switch to it in a single step.
git branch new-feature
git checkout new-feature
# or in one command:
git checkout -b new-featureAfter you have worked in the new branch and committed your changes, you need to merge them back into the main branch. This is done with the merge command. First you switch back to the main branch, then you merge the branch containing your feature into it. Git automatically tries to combine the changes from both branches, and in most cases this happens without any problems at all.
git checkout main
git merge new-featureResolving Conflicts
Sometimes two branches change the same line in the same file in different ways, and Git cannot decide which version to choose. This situation is called a conflict. When a conflict arises, Git notifies you and inserts special markers inside the conflicted file. Your task is to open this file and decide which part of the code should remain and which should be removed.
<<<<<<< HEAD
my change
=======
change from the other branch
>>>>>>> new-featureWhen you see these markers you decide which code is correct, then remove the unwanted part along with the special markers. After that you save the file, add it to the staging area again and make a commit. In this way the conflict is resolved and the merge process is completed. There is no need to fear conflicts, they are a natural part of any teamwork, and over time you will learn to resolve them quickly.
git add conflicted-file.php
git commit -m "Resolved merge conflict"Remote, Push and Pull: Working with GitHub
So far we have worked only with the local repository on your computer. But to share code with others or store it safely, you need a remote server. This is exactly where services such as GitHub and GitLab come to the rescue. A remote is the remote copy that your local repository is linked to. The following command connects your local repository to a project on GitHub.
git remote add origin https://github.com/user/project.git
git push -u origin mainThe push command sends your local changes to the remote server so that other members of your team can see them. Conversely, to bring changes made by others onto your own computer, you use the pull command. When working in a team, it is considered good practice to pull every day at the start of your work, because this supplies you with your colleagues' latest changes and prevents many conflicts.
git pull origin main.gitignore and a Proper Workflow
Every project has files that should not be tracked by Git, for example configuration files containing passwords, temporary files, or library folders. To hide such files from Git, you create a file named .gitignore in the root of your project. In it you write a list of files and folders that should not be tracked. This file helps keep your project clean and secure, and your repository compact.
node_modules/
.env
*.log
vendor/
.DS_StoreThe most efficient workflow is to create a separate branch for each new feature or fix, work in it, and merge it into the main branch when finished. This approach is called the feature branch workflow, and it keeps the code stable. The main branch should always remain in a working, stable state, while all experiments are carried out in separate branches without affecting it until they have been fully tested.
Learning Git may seem complicated at first, but the core commands covered in this article handle ninety percent of your daily work. The best way to learn is through practice: create a small project, make changes to it, play with branches and deliberately create conflicts so you can practice resolving them. Over time Git will become your most reliable assistant, and you will no longer be able to imagine working without it.