Whether you work alone or in a team, Git is an essential tool. Developers will use Git to help them track the changes in their code base overtime. It is sometimes referred to as a time travel machine but we only travel in the past. It is important to understand that you do not always need GitHub to work with Git, you can initialize Git in your project and start tracking your code but for this post, we will assume that the main code is in the cloud (GitHub).
There are a lot of commands we use when working with Git. But for your day-to-day job as a junior developer for example, you will need just few of them.
git clone
A clone is a copy or a replica of something. This command is by far one of the most self-descriptive of all. Yep, you guested, it is a command that gets us a copy of the repository aka project we have in the cloud into our local machine. To run the code, open your terminal where you want to save the copy of the project and type the following command:
git clone <url of your project on GitHub>
git branch
After cloning the repository, we are on the main branch. When working on a project, it is not advised to work on the main (formerly master) branch since it is a meant to contain the final code. The final code is considered as the bug-free code in production. In other words, nobody touches main that is why we create new branches. A new branch bears the name of its purpose for traceability some branches are called "test", "release", "dev" etc. The naming convention really depends on the team. For my part, the branch bears the name of the ticket on the project management tool (Taiga). To create a branch, run this command in your terminal:
git branch <chosen name or ticket's name>
git pull
To get all the changes on a particular branch, we need to pull them. This command will help us get all the changes present on the remote branch and merge them into the local branch. With this command, both the local and the remote branches have the same information. One thing we have to notice with this command is that if two developers have been making changes on the same line of code, a merge conflict can occur and how to fix it alone is another topic. Run the following command to pull all the changes from your remote branch into your local branch:
git pull
git checkout
Creating a branch is a crucial part in tracking your project with git but that is not all. We must work on it and to do so, we have to leave (checkout) the current branch we are on to the new branch we created and start working on it. As we realize, it is simple English. In fact the language is so intuitive that it is almost impossible to miss the point. To move to a branch new or existing, open your terminal and run the following command:
git checkout <branch's name>
git status
By far one of the most used git commands. This command is meant to give the status of the current branch we are on. If the branch has been modified, it will git you the name of the files that have been subject to modification with their location. This will allow us to make a last check on the modifications that have been made and see if they suit us. If the branch has no modifications, when we run the command, we will see a message like "Already up to date". In summary, this command helps us see files that have been modified and are ready to be added to our next commit, files that have been modified but not staged and new files that have not yet been tracked by Git. To check the status of your current branch, run the following command in your terminal:
git status
git add
After modifying the status of a file or creating a new file in the current branch, it is just natural to stage it so we can include it in our next commit and that is the role of this command. With this command, we are basically telling git to record a copy of the current file as it is before we commit it. It is important to understand that this command does not commit the changes, rather keeps a version of the file that we will commit later on. To stage your changes, run the following command:
git add <file name> to stage a single file
git add . to stage all the modified files
git commit
This command to me aims at sealing the faith of a one or many files. In other terms, we are telling Git that we are ok with all the changes we made at this particular moment so keep a permanent copy of it. For better understanding and traceability, we must add a message to our commit therefore the "-m" flag. The commit message must be clear and concise so other developers (or ourselves) working on the projet can understand what the modifications are about. To commit your changes run the following command:
git commit -m "<message>"
git push
The last but not the least command used has to be "git push". It transfers the local changes to the remote repository (GitHub in our context). But to push those changes, it has to first check if the branch points to its remote branch with the same name. If the remote one does not exist, Git will provide a command that will set up an upstream with the same name. The command will look like this: git push --set-upstream origin <local branch's name>. I never type this command since it is always provided by Git. On the other hand, if the local branch has a remote peer and is up to date then, we can simply push the changes by running the following command:
git push
As mentioned somewhere in this post, Git has a lot more commands used to perform specific tasks. But these are the ones I use the most in my day-to-day job. What command will you add to this list as your day-to-day most used Git command?
Top comments (9)
I actually can't remember the last time I manually used a
gitcommand. I've always found the graphical clients to be much more useful and intuitive. GitKraken is my client of choice.Nice comment here. I had the graphical client too (a different one) but it seemed overwhelming to use. Too many things shown but the command line goes straight to the point one command at a time. Will definitely check GitKraken thanks for sharing.
I'm the opposite - I am very bad with GUIs and struggle to use them, whereas text commands make sense to my brain.
I’m still in the CLI myself. I don’t trust these tools, and some of them want me to allow them to OAuth in as me on GitHub, which is a non-starter.
I still use the CLI for pretty much everything. I’m glad to see others picking up these important skills.
Congrats Audrey, very interesting post! Just to complement a little bit, I believe that git merge is also a very important command for every dev to have in its own "git cheatsheet" to solve simple conflict issues when working in multiple tasks or with other developers on the same branch, and it is a must be for devs who like to use git from the command line.
Sometimes "git rebase" save my life
Very interesting, as a beginner I think this commands are enough. Thanks for sharing
I got a revision
Thanks
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more