📚 In my recent blogs, I've shared my Linux learnings so far. 🌐 Although I haven't yet written about Linux networking, I’ll soon compile what I’ve learned in that area. Today’s topic, however, is version control! 🔄 I’ll be focusing on GitLab, which is similar to GitHub, and I’ll share everything I’ve learned about using it. 🚀
Why There Is a Need for Git? 🤔
While working on a project different developers work on the same code 🧑💻👩💻. They have different roles in that project, like frontend, backend, testing, etc. 🖥️🔍 And we need to share the same code with different developers. So, how do we share the code with each other? 🤷♂️
Here comes Git! 🚀 In Git code is hosted centrally on the internet in a code repository 📂🌐. Now every developer has an entire copy of the code locally 💾. Code is fetched from the remote repository 📥 and pushed to the code repository 📤. Git knows how to merge changes automatically 🤖.
But there’s a problem when the same line is changed by two developers 🛑, Git can’t fix it, and it causes merge conflicts ⚠️. The best practice is to keep pushing and pulling to the repository 🔄. Version control keeps a history of changes 📜, and you can revert the commits you made ⏪.
Basic Concepts of Git 🛠️
Git is the most popular version control tool 🌟. Here are some key concepts you should know:
- Remote Git Repository 🌐: These are centrally hosted repositories. You can manage them using various version control tools like GitHub, GitLab, Bitbucket, etc. 🖥️ It can be public or private 🔐.
- Local Git Repository 💻: These repositories are hosted on your system.
- History of Code 📜: You can view your Git history by typing the command git log.
- Staging 📝: This is the area where you decide which changes to commit. Staging prepares the code for committing ✅.
- Git Clients 🔧: These tools help developers interact with Git repositories.
Note 📝: Companies often use their own Git servers, like Bitbucket.
How to Set Up a Repository 🛠️
There are different version control tools available 🌐. First, create an account on any platform. Here, I use GitLab, which is similar to GitHub 🖥️.
After making an account 📝, we need to connect the Git client with the remote platform 🌐. This involves authenticating GitLab to enable pushing changes from the local repository 💻 to the remote repository 📂. For this, we can set it up by adding an SSH key 🔑.
After doing this 🔑, GitLab can authenticate us when pushing or pulling from the repository 🔄. You can check the next steps to clone the repository 📂⬇️.
Work with Git ✨
There are mainly 3 stages 🛠️:
- Working directory 📝: Where new files are created.
- Staging area 📂: This represents that files are ready to push. Use git add to get the file in the staging area so it can be committed.
- Local repository 💾: Here you can commit the changes. This is your system on which you are working.
I am creating a basic file to show how we work with Git. I create a README.md file 📄. After creating, type the command git status. This command shows the current status of the local Git repository 📊.
After that, we use the command git add . to move the file to the staging area. Then, type the git status command. It will show the file in green color ✅, which means that the file is in the staging area. Now it can be tracked.
It's time to commit the changes 🎉. Use the command git commit. Here is the screenshot of the commands I have used 📸.
Now it is time to push the work to remote repository that is on GitLab. Simply just write the command git push in the terminal it will do the work.
Note:- If you stuck and getting error I suggest use StackOverFlow or use ChatGpt to resolve the issue.
Initializing a Repo 🛠️
If you have worked on your project locally and you want to push it to your GitLab account 🐙, there is a way to make that happen.
You need to make that folder a Git repository 📁. Use the command git init to initialize a Git repo. Now follow the same steps above.
But you might notice there is an error while pushing the code 🚨. This happens because there is no destination defined. To fix this, create a repository on your GitLab account 🛡️. After creating it, you will see a section "Push an existing folder" 📋. From there, copy the git remote add command and paste it into your terminal 💻.
However, you might still get an error related to the master branch ⚠️. To resolve this, use the command showing in your terminal: git push --set-upstream origin master 🔗. Now the branch is connected too ✅.
Branching Concepts 🌿
The Master Branch 🛠️ is known as the main branch. It is created by default when you initialize a Git repository. New features, bug fixes, and stacks of changes in the master branch help divide the work among developers by creating a branch for each feature ⚡.
How to create a new branch? 🤔
The best practice is one branch per bugfix or feature 🐛✨. Developers can commit without worrying about breaking the main branch 🚀. Once changes are complete, merge the branch 🛡️. Then, a new version can be released 🎉.
However, large feature branches 📏 that stay open for too long increase the chance of merge conflicts ⚠️. By having separate branches, the main branch remains stable ✅.
The git pull command is used to refresh new changes in the remote repository 🔄. To switch between branches, use the command git checkout <branch name> 🔀.
To create new branches in the CLI 🖥️, first type git checkout master to switch to the master branch. Then, create a new branch by using the command git checkout -b <branch name> 🆕. This command will create a new branch and automatically switch you to it 🚀.
However, this branch exists locally only 🗂️ and does not replicate in the remote repository 🌐. To sync it with the remote, make changes, commit those changes, and use the command:
git push --set-upstream origin <branch name> 🔗.
Note 📝: In a project, there are typically two branches:
Master branch 🛠️ (main branch).
Develop branch ⚙️ (ready for production).
Merge Requests 🔄
Merge requests are typically done by other developers 👨💻👩💻. Afterward, experienced team members 👓 review the code before merging the changes.
This process ensures that the master branch 🛠️ remains stable ✅.
Deleting Branches 🗑️
After completing work on a branch, it’s a good practice to delete it 🧹. Branches can be deleted in two ways:
Through the remote repository 🌐:
Simply go to the branches section in your account and delete the branch 🖱️.From the local environment 🖥️:
First, switch to the master branch and pull the latest changes:
git checkout master && git pull 🔄.
Then, delete the branch locally using the command:
git branch -d <branch name> 🗂️.
Rebase 🔄
Imagine you’re working in a bug-fix branch 🛠️ and have made some changes. At the same time, another developer also makes changes in the same branch 🔀 or in the remote repository 🌐. The changes made in the remote repository won't be reflected in the local repository of the first developer and vice versa.
In this scenario, Git will show that there are some changes. First, you need to pull those changes ⬇️ and then push your own changes ⬆️. This could result in multiple commits being pushed, which is not a best practice ⚠️.
To solve this, use the command:
git pull -r🔗.
This command rebases the changes, stacking your commits neatly on top of the latest remote changes 📚.
.gitignore File 📄
When you work on a project in your local environment 🖥️, certain files are generated, such as dependencies, build files, and other temporary files ⚙️. To exclude these files or folders from being tracked by Git 🛠️—especially those specific to your editor—you can use a .gitignore file 🚫.
For example, in build folders where compiled code is located 🏗️, you can create a .gitignore file and list those files or folders to prevent them from being tracked. This keeps your repository clean and focused on important files ✅.
./idea/*
/build/*
/node_modules/*
To stop tracking a file use command git rm --cached <folder name>.
To revert commits use command:-
git reset --soft Head~1
git commit --amend
git push --force
git revert <commit id>
And git merge 🔄 merge the changes from the master branch 🛠️ to another branch 🔀, make sure that your local master branch 🖥️ is up-to-date ✅ for that use git checkout master, git pull, go back to your branch 🔁 git merge master 🔗.
Resources 📚🌐💡
Conclude ✅🔚✨
In this blog, I’ve covered the basics of Git 🧑💻, but there are still plenty of concepts I couldn't cover 📚. Git is a vast tool with much more to explore. In my next blog, I will dive into build tools 🔧, starting with npm for JavaScript and Maven and Gradle for Java applications ☕. Stay tuned for more! 🚀
Top comments (0)