At the moment, we have a repository with two commits. The contents of the hexlet-git directory look like this:
ls -a
.git
PEOPLE.md
README.md
Before we continue experimenting, let's add our repository to github.com. A saved repository can be retrieved at any time to continue working in it from the last commit you added to it. This is useful in case we accidentally delete or change the local repository in such a way that it becomes impossible to work with it.
- Create a repository on GitHub. Call it hexlet-git. It's important to create an empty repository, so do not check the boxes that add files
On the repository page you will see ready-made commands to connect the repository you created on GitHub to an existing repository on your computer
Follow these steps:
# We'll look at these commands in more detail later git branch -M main git remote add origin git@github.com:<GitHub username>/hexlet-git.git git push -u origin mainUpdate the repository page at github.com. Have a close look at the page's interface and the contents of the repository. Note that the .git directory is missing. We'll find out why this is so in a future lesson
After this command, the repository created on github.com will "connect" to the local hexlet-git repository. You may have a couple of questions at this point. Why does it need to connect? Isn't it the same repository?
They're actually different repositories. Git is one of so-called distributed version control systems. Git doesn't have a central location where one main repository resides that all the developers work with from their computers. Every developer's git has its own full-fledged repository as well as the repository on GitHub itself. These git repositories are linked and have a common history and ability to share changes. In the example above, it's the git push command that sends changes to the newly created repository.
Right now, after running the commands above, the local and remote repositories are identical. But they will diverge all the time during the development process, and programmers must remember to synchronize changes, adding new commits into the repository and pulling commits made by other developers.
It doesn't matter what changes are made in the local repository, all the commits will go to GitHub only after the git push command is used. Don't forget to do it, it's not unheard of that a developer has accidentally deleted the local repository and forgets to push the changes.
Next, we will try to download the repository from GitHub as if we didn't have a local copy. To do this, delete the hexlet-git project directory from your computer.
Cloning
The repository created on GitHub is public. Anyone can clone it on their computer and start working with it as if it were their own personal repository. The only limitation is that you will not be able to make changes, because GitHub does not allow you to change other people's repositories directly.
Cloning is a basic operation when working with remote repositories. Projects that programmers work on can always be found on services like GitHub. To work with them, you need to clone the repository to your computer. This is done by using the git clone command. The full clone command is available on the repository page. To do this, click the big "Code" button, go to the SSH tab and copy the contents.
git clone git@github.com:<GitHub username>/hexlet-git.git
cd hexlet-git
ls -la
# If this is the first time
# Then you will probably see a message like this
The authenticity of host github.com cannot be established. RSA key fingerprint is SHA256: хххххххххх Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added github.com (RSA) to the list of known hosts.
# Type 'yes' and press Enter
We've got an exact copy of the repository we had before we deleted the hexlet-git directory.
Pulling changes from GitHub
Developers don't only send changes to GitHub, but also take changes from there. More often than not, these are changes made by other project developers, but this isn't always the case. It's not uncommon that one developer works on a project from different computers, each with its own copy of the repository (this is the only way that git works). In that case, you should always run the git pull --rebase command before starting, which downloads new commits from an external repository and adds them to the local repository.
Articles often say that calling a git pull is enough, but this can create unnecessary merge commits that damage the change history. Working properly with git pull requires knowledge of things like branching and git rebase. They're quite complicated for newcomers and we'll look at them later when you have a little experience with git.
Summary
Let's make a quick summary. We created a repository with several commits. This repository has been added to GitHub and can be cloned for further development. How can we benefit from git right now? We have a backup copy of the code on GitHub. At the very least, we don't need to be too scared of losing our code. Now it's easy to restore it if needed and share it with others.
It's also worth mentioning that GitHub, although the most popular, is not the only repository hosting site. Besides GitHub, Bitbucket and GitLab are quite well known. You can even put GitLab on your server and host repositories within your company, which many people do for security or money-saving reasons.
Do it yourself
- Follow all of the steps in the lesson
- Add a new NEW.md file with any arbitrary content you like to the repository (you'll need to commit)
- Upload the changes to Github using
git push - Refresh the repository page on Github. You should see the last commit, i.e., the changes that were made by it
