| Digital Notebook

an image showing code versioning

Get familiar with basic Git commands

on

When I first started using the terminal and writing commands, it all felt very complicated. I worked with a senior developer at that time who knew all of these commands, what they do and what do the errors mean.

To me that looked like an impossible task and something I’d never be able to master. Well, I was wrong ? The same senior dev taught me all of them and explained all the why’s and how’s I’ve asked about.

When you start it is a bit scary looking but it ain’t that complicated ?
Let’s talk about the most basic git commands you’ll want to use to start with.

Let’s get started ?

Table of contents:

How to get someone else’s repository?

The first thing you will need to do is go to the repository of your choice and press the green coloured button that says ‘code‘. There you will see a couple of options (pic below). This is where we’ll see a link or a command we could copy paste into our terminal.

We’ll grab the link we see up there and open up our terminal.
Find the folder you want to save this new repository in and change your directory in terminal. Once you’ve done this we’ll be able clone this repository using a git clone command like this:

git clone https://github.com/Junior-Developer-Group/junior-coding-team.git

How to get all recent changes from an updated repo we’ve just cloned?

To get recent changes we’ll have to use another command called ‘git pull’. This command will help us ‘pull’ all changes from the live version of our chosen repository into our local repository on our machines.

If that is a bit abstract think of it this way.. There’s an apple tree in front of you and you really want an apple – but you need to reach out to get it and then ‘pull’ it from the tree towards yourself. With git and repos we’re basically doing the same thing – pulling the ‘apple’ we wanted towards ourselves.

This is how that looks in practice.

If you’re pulling from ‘master’ or ‘main’ branch:

git pull origin master 
git pull origin main

If you’re pulling from another branch that is not called master or main, you can do that too, just add it’s name at the end of the command. 

git pull origin 'your-branch-name'

Here I used the quotation marks around the branch name as we’re using dashes (-), this is optional but sometimes becomes a preferred option.

How to get a certain branch from the repository you’re working on?

The command we’d need to use here is pretty simple as well. The action of getting or taking a branch would be called ‘checkout‘. Imagine the word checkout we use here like you would checkout a movie back in the day, when we used to visit video stores and rent movies. Here is how it looks:

git checkout 'your-branch-name'

How to create your own branch?

The hardest part of creating your own branches is naming them. Have a good think and don’t name your branches something long, something not descriptive or something too abstract/hard to read.

How to pick a good name?
That you will learn with time, don’t be scared and experiment. Usually you will name your branch after a ticket you’re working on, e.g DEV-29-adding-footer-styling. Sometimes you won’t have a ticket and you’ll have to think of something short but also creative, sometimes you’ll want to keep little clues about versioning in the name.. Many options to pick from – experiment and see ?

To create your own branch we need to use the ‘checkout’ command from above again but with a small change:

git checkout -b 'your-branch-name'

The change we’re adding is the ‘-b’ part. This essentially tells git to create a new branch and you just give it your own name at the end of the command again.

Once we’ve got our branch set up we can start making changes in any files we wanted to or needed to – safely.

How to add/restore local files before committing them?

Before we commit our changes we can decide which files we want to add (save) and which ones we want to restore. This is where we will run these commands:

git status
git add 'file-name-here'
git add .

To check the current status of changes/files we’ve worked on we will use ‘git status’. That will come back with a list of files in two colours. Red ones being the ones you modified and not added. Green ones being the ones you’ve modified and have added previously.

To add a particular file, we will need to add it’s name at the end of the ‘git add’ command. This will then add just that one file and won’t add any others you’ve worked on.

To add all files you’ve worked on you can use the ‘git add .’ command. The dot at the end replaces the word ‘all’. It will include everything that has been touched or changed or added or deleted.

Now when all your changes have been ‘added’ you need to ‘commit’ them.

If you want to revert your changes:

To reverse your local changes you can use ‘git reverse’ command or a ‘git reset’ command. Let’s have a look at both:

git restore .
git restore 'file-name-here'


The first command (the one with the dot) will restore all of your changes so be careful what you’re doing.

The second one will only revert the changes in the file you chose by adding the file name at the end of the command. All other files will stay the same as they were and nothing will be changed for them.

How to commit your changes?

If we wanted to save something we would use the word ‘commit’. With this command we will save something for later or we will sort of register our changes before we send them back to the ‘live’ repository.

When we’re committing something we’ll need to write a commit message. This is done using a ‘git commit‘ command which looks like this:

git commit -m 'your message here'

We’ve touched upon the ‘commit’ part but we haven’t spoken about the ‘-m’ part. This bit will just add a new commit message when saving your work.

We set this message to describe our change or say what we have fixed/worked on. It’s not meant to be long, just a couple of words, but it’s important to keep it useful.

Things to avoid would be setting ‘small changes’, ‘adding things’, ‘fixes’ and similar descriptions as your commit message. To try and see why, imagine that you had 50 changes sent to you for a review and they all had ‘small changes’ as their commit message – we’d get lost real quick ?

Now when we’ve committed all those changes, we need to push them.

How to push your changes to live repository you want to see the changes on?

Pushing changes means sending your works to the original repo. Remember how we ‘pulled’ the apple we wanted before? Well now when we’ve eaten it we’ll try to ‘push’ it away as we’re done with it now.

With git, once again, it’s the same. Once we’re done with our branch (apple) we’ll push it away, not towards a tree but towards our master or main branches.

This is how that will look like:

git push origin master

As you can see this command with push our changes to master branch. After you press enter, your terminal will look a bit crazy for a second and then it will stop, presenting you with a link to your brand new Pull Request ?

If you wanted to push your changes to any other branch you’d just change the name of your branch like this:

git push origin 'your-branch-name'

How to keep your branch updated and conflict free?

While working with teams you might find yourself in a situation where you’ve all been working on the same file, there has been some changes to ‘master’ / ‘main’ branches or you just need to update your branch with whatever code ‘main’ or ‘master’ have in them.

This was a fairly new thing for me and when I got told about it by another developer it simply blew my mind ? It’s super simple so let’s get to it now:

This is what you might see:

So we’ve got a conflict with our style.css file as we’ve got some changes on ‘master’ / ‘main’ that we haven’t added to this branch/this PR.

To solve this we’ll use a cocktail of git commands, looking like this:

git checkout master
git pull origin master

git checkout 'your-branch-name'
git merge master


In case you wanted this updated with ‘main’ as the branch name for easier copy/paste, here it is:

git checkout main
git pull origin main

git checkout 'your-branch-name'
git merge main

As we discussed before, if you needed another branch you’d just replace the branch name at the end of the command. Now what does it all mean:

With first two commands we’re getting the fresh changes from our main/master branches. Then we switched to our own branch and used ‘git merge’. That command will take whatever it was that was new, and paste it into our branch.

At this point you might see conflicts – if you’ve all been working on the same file. There will be a message in terminal and a popup will appear in your IDE of choice. At that point it will ask you to pick which changes you want to keep inside of your branch. All you have to do is read and see which ones you want to keep – but be careful!

If it becomes too complicated and you find yourself in waters too deep, ask someone for help and tell them which commands you’ve used so they can help you out quicker ?

Wrapping it up!

That’s it! Well done for reading so far, I hope you learned a couple of new things or at least clarified some doubts.

As usual, I’m really interested to hear about your progress and projects you’ve worked on. To share some good news you can either find me over on Instagram or join our Junior Developer Group ?

Fundamentals

Leave a Reply