Last Updated:

Git : Basic | Quick Start learn with this simple tutorial

Introduction

Git is a decentralized version control (DCM) system.

In the modern world, it is used in any IT project larger than very small. Why do we need it, because I keep my projects?! The answer is simple: "You work, you work, for example, write a diploma. They wrote about two-thirds. Breathed. You're great, and that's the night before the delivery. We went for another batch of coffee. Come to the table, and your beloved cat decides to run under your feet. Coffee flies to the laptop, the screen goes out, the cat flies into the window, the whole house rises to its ears when you hear your exhausted cry. It was as if there was no diploma." And that's just one example. This can be listed almost endlessly, and such stories will be taken from the real life of real people. Accidentally deleted the only copy from the flash drive, the hard drive was covered, the computer was stolen, power outages and the burning of the PC ...

Benefits of Git Version Control

 

Git will not save your computer, but it will save your work, developments, and a couple of hundred nerves. But this is only if you use a version control system. In addition to safely storing your data, Git provides the opportunity for several people to work on the same project without having to run to each other with flash drives or disks containing the source codes of programs. "I do this, you do this. We do it in two branches, then merge it into one." Two tasks are performed in parallel and do not interfere with each other. And then, at the very end, when all the errors have already been corrected and brought to the appropriate form, the achieved results are combined (for example) into one directory and this very directory is the final result of the project. This example is exaggerated, but shows on elementary things the meaning of the need to use SLE.

Another example: you write, write... and you don't notice how you make a mistake that "puts" the whole system. Not nice, right? But! You've used a version control system and remember that seven saves back started working on the code that brought down the system. What should I do? Correct! Return the state of the system to the time when it worked as expected of it. Thanks to Git and the commits that we did, we roll back seven commits and voila! Our system works as expected of it and there is no code in the code that did all that bad.

A small illustration of why Git is needed when working as a team.

 

Explanation of the illustration:

  1. the image at the top left shows the visualization of branches at some selected stage of the project;
  2. two developers (left) are working somewhere (one in Miami, the other in Vorkuta) on JavaScript code, a third developer (right) is working (in Singapore) on styles;
  3. using Git and some code hosting (we will talk about them almost at the end of the article), they do not need to transfer files to each other's mail or Telegram;
  4. the first is enough to say "I started the animation on the client, everything is stable";
  5. another with the help of a couple of elementary commands (compared to really complex ones) will download all the developments of the first developer;

Software Installation

  1. Download the required package from the official website. You can choose for different operating systems here. Or download directly
    1. download only from the official site, assemblies of other smart people may not be safe and will only harm your system;
    2. for Windows here (this article will consider the Windows version, Windows 10 will be used, but this does not change the essence of the matter, only some nuances regarding security that will be considered, and the difference in the graphical interface);
    3. for linux instruction here;
  2. Run the installation like any other program (the installation process with correct flag placement will be illustrated below), if you are interested in the details of installing Git on a computer with Windwos, then I recommend reading the following article;
  3. *On Windows 10, when starting the installer, the operating system will require permission to install, you need administrator rights;
  4. Install Git on a Windows computer
  5. Install Git on a Windows computer
  6. Install Git on a Windows computer

You will see a CMD window (aka Command Prompt). If this happened, then everything is fine, you can close it. If the window does not open, then go to the "Start" menu

Open the Start menu

At this point, the Git installation process can be considered complete. As practice shows, this stage is not problematic for most novice programmers, or people at least somehow connected with computers.

Set up Git

Configuring Git consists of entering a set of commands with the necessary arguments. In fact, it sounds just as much as it is. It's scary only the first time, then it becomes commonplace.

For a complete and competent setup, we will need:

  1. active mail (yandex, google, mail - it does not matter which);
  2. come up with a login in English;

Open "Git Bash", it should be in the "Start" menu. A Command Prompt window will open, it will be slightly different than the usual command line (this applies only to the design component). Below is a screenshot showing the difference.

Explanation:

  1. the window at the top is Git Bash;
  2. the window at the bottom is the CMD (Command Prompt) window);

As you can see, the difference is in color. When working with Git, Git Bash is used, since although it is similar in its functionality to the CMD (you can carry out the actions in Git Bash the same as in the CMD), but still they are different. Git Bash picks up Git settings on the fly, thereby allowing you not to use passwords every time you send to the server. CMD settings are not picked up, but Git functionality is available from CMD. If you are interested in reading about the setup in more detail, I recommend reading this article.

Let's start the configuration:

  1. Open Git Bash, a window should appear;

In the config, which was opened by the last command, all the entered information will be displayed. Make sure that it corresponds to reality in those items that were filled in paragraphs from the 2nd to the 5th inclusive.

This completes the Git configuration. If you are an experienced programmer, but could not remember the points above, you can finish reading the article and move on to work. For the rest, I recommend continuing to increase their knowledge.

Code Hosting

Git is just a system, a tool to implement. In order to exchange best practices, you need such a place, somewhere on the Internet, where there will be access to data for others. That's how code hosting came about. The most popular at this point in time are:

  1. GitHub is used mainly as a hosting for development in the field of open source software (Open source projects). Link to GitHub here;
  2. Bitbucket is used for corporate needs, private repositories, a good place for commercial development ranging from landing page to order and ending with multi-million enterprise projects. Link to Bitbucket here;

Which one is better to use? Both. GitHub is perfect for storing portfolios or developments that you want to share. Below you will learn how to set up a secure SSH connection for GitHub and Bitbicket, respectively. I recommend signing up for GitHub and starting to use it, as it's the most user-friendly for people who aren't familiar with code hosting at all. When registering for each of them, I recommend using the same mail that was used when setting up Git, in the future there will be fewer problems and life will be happier.

Set up SSH or securely connect to your hosting

To interact with the code hosting, you can use an HTTPS connection or an SSH connection, the latter is the most preferable. To use an HTTPS connection, you do not need any additional settings, but annoying moments will arise during the use process (manual authorization and the like are required). With SSH, circumstances are different, pre-settings are required, but later there will be a number of headaches less. You need to create access keys that will later be used by our installed and configured Git and specific code hosting. Let's look at creating and configuring an SSH connection:

  1. Open Git Bash.
  2. type the command and press Enter

     

    1. a number of questions will be asked, press Enter on each question, do not enter anything, otherwise you will enter the password for SSH access every time you send;
  3. the completion of the key creation will be a rectangle displayed in the console, with "interesting" content.
  4. go to the hidden directory where these same access keys necessary for the SSH connection are located using the command

    if there are no path errors, then the keys were created correctly;
  5. run the following command

    and the names of the files in this directory (id_rsa and id_rsa.pub) will appear on the screen);
  6. the file id_rsa contains your private key, it can never be sent to anyone, no matter how much it is asked of you - it is only yours and no one else;"
  7. the id_rsa.pub file contains a public key, which we will use in further configuration;
  8. read and copy the data of the public key, to do this, run the command

    on the screen will display a "terrible" line starting with "ssh-rsa" and then many letters of the Latin alphabet, select it with the mouse from the beginning (with ssh-rsa) to the end of the line and copy the key combination CTRL+C;
  9. at this point, the work with the keys on the client (that is, on your computer) is completed, then we will configure the server side;

Set up SSH access for GitHub

  1. open GitHub;
  2. go to your profile settings;
  3. find "SSH and GPG keys" in the menu on the left and go to this menu item;
  4. find the "Add SSH key" button and click on it;
  5. You will be redirected to the add SSH key page (or go to it directly here);
  6. fill in the "Title" field at your discretion, later this value will be needed only to navigate through the keys;
  7. the "Key" field must be filled in with the most "terrible" line (public key), which you did not forget to copy;
  8. click the "Add SSH key" button and the key is added;
    1. if there are errors - check if you copied everything, GitHub will tell you what the error is;

Set up SSH access for Bitbucket

  1. open Bitbucket;
  2. click on your avatar at the bottom, a small list will open;
  3. find "Bitbucket settings" in the list (or follow this link);
  4. find in the menu on the left, but not on the edge of the screen, the item "SSH Keys" and go to it;
  5. find the "Add key" button and click on it, a window will open;
  6. fill in the "Label" field at your discretion, in the future the value of this field will be needed only for navigation by keys;
  7. in the "Key" field, place the copied public key (the same "terrible" line);
  8. click the "Add key" button and the key is added;
    1. if there are errors - check if you have copied everything, Bitbucket will tell you what the error is;

First commit

Open the repository you created. Depending on the hosting of the code, find the "Download" button of the current repository. A small window will open in which there is a choice of the type of connection. We choose an SSH connection, as it is the most preferable due to the security of the traffic movement tunnel being created. If you select one of the two connection types, the download link will change.

  1. copy the link and go to Git Bash. Type the following command:

     

    1. The very first time you clone a repository over an SSH connection, Git may ask you if your IP address is correct;
    2. Answer in the affirmative;
  2. A new directory will be created in the directory where cloning was invoked with a name identical to that of the cloned repository;
  3. There is only one directory in it, and then the hidden one, called .git, you never need to touch it with your hands, especially if you do not understand anything about it;
  4. Now create a file (called Hello-world.txt) in the .git directory, write down the phrase "Hello world" in the file, not forgetting to save the recorded text;
  5. Go to Git Bash and run the command:

    the console will display a list of untracked files that are not tracked because they are not yet tracked. The oil is mental, but that's the whole point;
  6. Let's start tracking this file, to do this, you need to run the command:

    Or:

    this command will commit all changes to the local repository;
  7. Run the command

    again and specify that before the name of your file was written in red, now the name is green, the header has also changed, now it is a tracked file;
    Repository change status
     
     
     
    Shell
     
    1
    git status

His Majesty Commit

  1. To upload your development to the hosting, the manipulations done are few. Now you need to create a commit. A commit is a container with a custom description of the changes and the files themselves that were attached to the commit;
  2. Execute the command:

    You can write anything as a message, but the correct tone is to indicate the manipulations performed. Briefly but clearly;
  3. Run the Now file command

    from the description, but the number of commits that are not committed to the server is one. This commit now records our changes, and if necessary, we can roll back to this commit in the future;

Push or send to the server

Why send the latest versions of files to the server? Yes, so that the whole team has remote and free access to the latest files and has the opportunity to do its job as efficiently as possible. There are tasks in which the effectiveness of one team head depends on another, albeit partially. Consider sending changes to the server after the changes have been committed.

  1. To submit the committed changes, run the following command:

     

    1. Perhaps after cloning an empty repository, git will ask you to explicitly specify which branch we want to upload our changes to;
    2. Let's add the previous command and execute it:

       
       
       
       
      Shell
       
      1
      git push origin master
  2. If everything went well, then we will not get any errors;
  3. You may receive warnings due to the difference in line endings (depending on the operating system). But they will not affect the commit in any way, thanks to competent settings;
  4. We go to the code hosting, where they poured. We are looking for a repository where a fresh file has just been uploaded, and admire its contents on the server, where you can go from any device with connected Internet from any corner of planet Earth;

Creating branches and how not to interfere with others

In teamwork, the contribution of each head is important. One is lazy and unlocks more than it does – vulnerable points appear in the project. It is not necessary to plow like a Stakhanovite, it is enough to perform your functions and tasks competently, it is enough and not according to the principle of Vovochka. If you don't know, ask Team-Lead or the person responsible for the assigned task. Everyone has their own area of responsibility and therefore it is important to help each other, and not to interfere.

 

Why branches if there is a master?

If you use one root branch (master) to infuse your changes to all team members, then you will constantly have to update the data to everyone, because you can not pour your own without accepting the changes of the other. We get massive inconvenience and conflicts of versions, which Git will inform us about in an "affectionate" form. Therefore, branches or branches were created. In the world, the root branch (aka the master branch) is used as a reference for the repository (or project, depending on the scale), so it gets data only with the permission of Team-Lead or the person responsible for this part of the project. Anyone involved in adding their data or making changes to existing files should use branches. Since the reference branch is the master branch, additional branches should be drawn from the master branch.

Branch is a branch of the project from a certain branch, which allows you to modify files in parallel with other team members and upload to the server without fear of spoiling the reference branch.

Let's consider creating and working with a new branch:

  1. "pinch" from the root directory, to do this, run the command

    to create a new branch, but you are still in the master branch (look at the argument in parentheses near the path indication), you need to switch to a new branch;

     

    1. Important point: the name of the branch can be only one word;
  2. switching to a new branch is done using the command

    look at the argument in parentheses near the path indication, there instead of master it will be newBranch;
  3. suppose that we did-did our task and want to put newBranch in an additional branch for the first time, for this you need to fix changes, add commit, but you should upload changes in a

    slightly different way actually, newBranch is only the name of the branch, instead of it you should use your branch name, later, being in an additional branch, you can use the usual
  4. Look in the repository, your branch appeared there, now your commits sent to the server will not interfere with the rest;

What's next?

And then you do your task, usually follow the rule: one branch - one task. The names of the branches correspond to the name of the task, usually with its unique identification number in the task list.

  1. do the task;
  2. commit atomic changes;
  3. check;
  4. edit;
  5. when you consider that the task is completed completely and meets the requirements established in the project - inform the person responsible for this part of the project or Team-Lead;
  6. the branch is checked;
    1. if everything is fine, then the additional branch merges with the root branch master;
    2. if the task is not performed correctly or incorrectly, then we finalize and correct;
      1. see point five;

Merge additional branches from the root

We finished the task, the solution was approved by the heads from above. It's time to pour your changes into the master reference branch. This is done either by the responsible person or Team-Lead, or by the developer himself, depends on the rules on the project.

Run the following commands:

  1. let's make a transition to the root branch
  2. merge the additional branch and the reference branch

     

    1. at this point, merge errors may occur if someone rules your files in parallel. These are the so-called merge errors, it is necessary to manually decide which changes we accept and which we reject;
  3. an automatic merge commit appears, you must upload the changes to the server

The end

With that, the Git version control system crash course is over! Thank you!