Git for the little ones

Disclaimer: if you are an advanced developer with X years of experience, please close this article. Here you will find absolutely nothing useful for yourself.

So, a little introduction. When I first had to commit to GitHub, I remember that I looked through a bunch of sources, and everything was somehow different from what I ended up doing.

In this article I will talk about how to make the first commit on GitHub, and how to make subsequent ones. Only my experience and the combination of the console and features of IntelliJ Idea + I have a mac os, so this is about it (important for installation).

Let's go.

Block 1: Installing git

Once again – here for mac os. If you have Windows, install git according to another tutorial and come here to step 2 – we will commit! The first thing we do is open a terminal and enter the command git –version. If you saw this answer: git version 2.47.0 (any version) – super! You have git, skip the “Installation” block and go to the “Usage” block

If not, you will see something like this: command not found: git

We will install git via brew. Don't be alarmed, brew is also installed with a couple of commands from the console. But it is important that there is memory on the laptop. I remember when I first installed git, I had no memory at all and it was just a challenge.

So, in the terminal we enter /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

Click enter. The download will begin and then you will be asked to enter your password.

Figure 1. Installing Homebrew

Figure 1. Installing Homebrew

Enter the password for your laptop (well, which is when you boot), press enter. If there is no password, just press enter.

ps You will not see how the password is entered, but it is entered, believe me 🙂 After entering the password and pressing enter, the following messages will appear:

Figure 2. Installing Homebrew (continued)

Figure 2. Installing Homebrew (continued)

When we reach the bottom line, press enter again. The lines will run, then they will ask you to enter the password again – enter it.

Figure 3. Installing Homebrew (continued)

Figure 3. Installing Homebrew (continued)

At the end you will see something like this. The main thing we are interested in is “Installation successful”

Figure 4. Homebrew installation completed

Figure 4. Homebrew installation completed

Now let’s check that brew is really installed, enter: brew –version and get the homebrew version in response: Homebrew 4.4.2

Now you can install git. To do this, enter into the terminal: brew install git

The download will begin, when it finally finishes, we enter git -version into the terminal again and get the following response: gir version 2.47.0

Hurray, we have git. Now let's move on to commits.

Block 2: First Commit on Git

Let me remind you that here I am sharing my experience and the approach that is convenient for me. If you know how to use git and are still reading this article (for some reason), your experience may be different and more convenient for you (happy for you!).

First, go to the GitHub website, register and then click on the plus sign and select “Create new” -> “New repository”

Fig 5. Creating a repository on GitHub

Fig 5. Creating a repository on GitHub

Fig 6. Creating a repository on GitHub

Fig 6. Creating a repository on GitHub

Enter the name of the repository and click the “create repository” button

Fig 7. Creating a repository on GitHub

Fig 7. Creating a repository on GitHub

The remote repository has been created. Cool, now GitHub is our assistant, because it gave us direct instructions with commands.

Fig 8. Instructions for commits from GitHub

Fig 8. Instructions for commits from GitHub

But we won’t follow it entirely (since here they suggest adding only the README.md file, and we will add all the files)

So, open our application in IntelliJ Idea, go to the Terminal tab, enter the command git remote -v

Fig 9. Checking for a connected remote repository

Fig 9. Checking for a connected remote repository

We get nothing, that's right. Because our local repository is not linked to any remote repository. Now we begin to enter one by one:

git init

Response in terminal:

Fig 10. Initialization

Fig 10. Initialization

With this step we initialized the repository.

Next, we’ll add the files we need to the future commit. You can add selectively (you’ll definitely figure this out later!), now let’s just add all the files with the command git add —all

Great, now enter git commit -m “first commit”

All files included in this commit will be displayed in the terminal.

Let's look at the command: git commit – well, this is the commit command itself.

The name of the commit is the command -m “first commit”, m means message, and the name itself is in quotes. Try to make commit names clear. In practice, the names of tasks from Jira are often used as a title, within the framework of which one or another edit is made in the project.

Next we enter: git branch -M master

We see that in the right corner we have changed the branch from main to master.

Figure 11. Switching to master

Figure 11. Switching to master

All that remains is to push the branch. We will push using ssh – how to generate an ssh key – I’ll leave a link to a YouTube video: https://youtu.be/cGcpVQlhbuI?si=pqBcD93ujVufTHV9

When the key is generated and added to GitHub, copy the line from our GitHub repository that begins with: git remote add origin (Figure 10)

For me it is git remote add origin git@github.com:my-git/just-test-repository.git

We use ssh, because with https there will be problems with login when pushing. If you suddenly accidentally linked a link via https, you can change it with the command: git remote set-url origin git@github.com:my-git/just-test-repository.git

All that remains is to do the push. Enter in the console: git push -u origin master.

In the console we see the following, hurray! Our first commit is done.

Fig 12. The first commit is pushed!

Fig 12. The first commit is pushed!

We update the page on GitHub and see all our files.

Block 3: Further development

To create new features in an application, it’s better not to do everything at once in the wizard, otherwise then these cherry picks (wow, that’s disgusting). Therefore, we create a branch. You can do it through the console, but here I always use the functionality of the idea, so what I bought for is what I sell for, as they say.

Click on the current master branch, select “new branch”

Fig 13. Create a new branch

Fig 13. Create a new branch

Enter the name of this thread. We usually do this (it’s different on every project!!!):

  • If we are cutting a new feature, then the branch is called feature/5778 (where the numbers are the issue number from Jira, there may also be a team name (like feature/TPS-5778) – in general, we are guided by the name of the issues in Jira)

  • If we fix a defect, the branch is called bugfix/TPS-9483

Let's go and call it something like this.

Fig 14. Create a new branch

Fig 14. Create a new branch

You see, there is a checkmark in the Checkout branch box. This means that after we create a new branch, we will switch to it, i.e. our master will be safe.

By the way, I have a telegram channel where I write about development of all sorts of things – here is the link for those interested 🙂 – t.me/crushiteasy

Class, click create. That's it, we're on a new branch. We cut features, add classes, service layers, daos, and so on, whatever your heart desires.

When you are finished and ready to send your development further, go to our favorite terminal (which is right in the idea in the project) and start entering commands:

When you enter the last one, the idea will tell you how to correctly push to the desired branch remotely (in red on the screen):

Fig 15. Push a new branch

Fig 15. Push a new branch

Copy this and paste it into the console again: git push –set-upstream origin feature/TASK-9090

Fig 16. Successfully pushed branch

Fig 16. Successfully pushed branch

The idea already suggests a link that you can follow to create an MP (aka PR) in the master branch.

Let's move on, create an MP (merge request) – everything is native there. Well done to us.

Block 4: Changes in PR/MR

Let’s say we’ve already pushed our commit, and then we realized that we had a bug with filters or the products decided to add more features to the same task, we continue development in the same branch. When everything is completed, we are ready to push again: – it is not recommended to spread many commits, so as not to get lost in them later.

There are two options here:

  1. Amend

  2. Squash

About each of them:

My practice is that in 99% of cases I use amend:

I made changes in the local repository, go to the terminal and write one by one:

About squash:

Here I use the help of the idea interface, to be honest 🙂 We made the changes, then we make a separate commit:

Then another commit, and another (well, as many as you need). At the end, before creating the MP (or before merging it into the master, depending on how the development goes), go to the Git tab, select the commits we need, click and select Squash Commits:

Figure 17. Squash Commits

Figure 17. Squash Commits

A window will pop up with the names of the first and second commits, delete them and enter a new common name (or leave the name of one of the commits – here, as you think is more logical/clear)

Fig 18. Name of the general commit

Fig 18. Name of the general commit

Click OK, go to the console and enter git push -f and get:

Fig 19. Let's push again!

Fig 19. Let's push again!

That's it, now we also go to GitHub and do MP.

Block 5: Merging branches and changes to the remote repository

After our (or not only ours) changes are merged into master (by the way, in my project the main branch is develop), we switch to it in Idea and update (essentially it’s git pull, but I’m closer to the development environment interface ): master -> update

Fig 20. Pulling changes from a remote repository

Fig 20. Pulling changes from a remote repository

When all the changes from the remote repository are pulled in, we will see the following (well, the number of files and commits may, of course, differ):

Figure 21. Changes from the remote repository have been updated

Figure 21. Changes from the remote repository have been updated

That's it, the git database has been issued 🙂 I hope it was useful for beginners!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *