Git is a distributed version control system DVCS , which is software that allows you to manage the source code of a software project during collaborative development without needing the support of a central server . Thanks to Git, programmers can record every change that is made to the code over time, compare different versions of the same file, collaborate simultaneously on the same program to implement new features without interfering with the work of other team members and do many other things which we will see in this article.
Git is open-source and can be used on various operating systems (including Windows, macOS and Linux) and is a truly essential tool for any software developer: major companies such as Google, Microsoft, Twitter and Linkedin use it, but it can prove really useful even for much smaller projects, even if they are run by a single developer.
Git features are so many, in this article we will explore the most important ones.
Git repositories
The main functionality of Git are the repositories , digital archives in which the source code of a software project is stored and managed and which keep track of the changes made to the files over time. A repository allows you to retrieve previous versions, compare the differences between versions, and collaborate simultaneously with other developers in teams without interfering with each other.
Repositories can be hosted on several hosting services that use Git as a version control system, such as GitHub , GitLab and Bitbucket . These tools make sharing, collaborating, and managing repositories easier and more efficient through web interfaces and project management tools. We in this article will explain how to use Git through the GitHub platform .
In the image you can see an example of a repository hosted on GitHub :
How to install Git
First we need to install Git on our operating system. Let's verify that it isn't already by opening a system terminal and issuing the command:
git --version
If the command is not recognized, we must proceed with the installation according to the operating system we are using.
Install Git on Windows
Download the installation file from this link and install it like any other program:
Install Git on Linux
To install Git from Bash or other Linux system shell, the command to use will depend on the distribution used; You can find the commands for the main distributions at this link . For example, if you're using Debian or a derivative distribution like Ubuntu or PopOS, the command would be:
sudo apt install git
Installing Git on macOS
We can install Git via the HomeBrew package manager :
brew install git
You can find other installation methods at this link
Configure Git user information
As we mentioned, Git allows us to keep track of the various changes made to the project over time. To help us keep the list of these changes neat and useful, we need to select a name and email address via the git config —global command . Global configuration (--global) allows us to set this information only once and use it in all Git repositories on our computer.
We carefully choose the name: it will be combined with the various changes you make and can be viewed by any collaborators who will have access to the same project. I chose the same username that I use on GitHub , but you can also use your first and last name if you want.
As for the email address, be sure to use the email address of your GitHub account: this will allow you to update your activity graph based on the various changes you make to your repos
Enter your email and your username or name + surname as follows:
At this point we will not be asked for a password, but the first time we will try to carry out an operation that requires authentication, such as pushing or pulling a private repository (we will see in the course of this article what these commands are for ) Git will ask for it together with the username to access the hosting platform we are connecting to, which in our case is GitHub .
As explained in the GitHub documentation , there are several ways to authenticate: if you wish, you can also simply create a personal access token GitHub documentation , which acts as an access password and must be repeated every time it is necessary to authenticate to perform any operation.
In this guide we will follow one of the simplest and most comfortable procedures by installing the GitHub CLI .
Configure access to GitHub using the GitHub CLI
GitHub CLI is a command line interface that allows you to interact with GitHub by performing many of the same operations that you can do on your site via a terminal.
Let's install it on our computer.
How to install GitHub CLI on Windows
On Windows we can download the installation file directly from the official site .
How to install GitHub CLI on Linux
If you use other Linux distributions find the guide in the repo , for Debian and Ubuntu copy and paste the following command into the terminal:
Now we enter the following command and we will be asked where we want to authenticate. We select GitHub.com and press ENTER.
gh auth login
# output
? What account do you want to log into? [Use arrows to move, type to filter]
> GitHub.com
GitHub Enterprise Server
We will be asked which security protocol we prefer to use when using Git : for simplicity we choose HTTPS .
? What is your preferred protocol for Git operations? [Use arrows to move, type to filter]
> HTTPS
SSH
We will be asked if we want to authenticate with GitHub credentials . We answer "Y" and we will be asked how we want to authenticate: we select with the browser and it will be opened automatically, or we will be shown a link to go to. In addition to entering the GitHub password we will also have to add a disposable code (one-time code) that will be provided to us by the CLI.
? Authenticate Git with your GitHub credentials? (Y/n)
> Y
? How would you like to authenticate GitHub CLI? [Use arrows to move, type to filter]
> Login with a web browser
Paste an authentication token
! First copy your one-time code: XXXX-XXXX
Press Enter to open github.com in your browser...
We insert the disposable code (one-time code):
We authorize GitHub CLI :
We enter our GitHub password and finaly we get wil this message
Git commands
Before talking about how to use Git in practice, we need to familiarize ourselves with its main commands. Using Git isn't difficult, but there are tons of features to get to know and master! Let's try to get an idea of everything we can do with Git by seeing in detail the functioning of the following commands:
git init
git add
git commit
git log
git push
git pull
git fetch
git clone and forks
git branch and git checkout
git merge
git status
git revert
git reset
After seeing an overview of the most common commands, we will see concrete examples of how to use them. You may have to review the various commands several times to understand how they work in detail. However, as specified at the beginning of the article, many of these will be easier to memorize after experimenting. So remember to use this section as a reference.
The git init command
The git init command is used to initialize a new empty Git repository in the current directory. Create a new (hidden) .git directory that contains all the configuration files and metadata needed to manage the repository.
git init
Once the repository has been initialized, we can add files using the git add command .
The git add command
The git add command is used to add the changes to the next commit. As we'll see shortly, commits are a sort of "snapshot" of the repository and describe the changes we've made. These changes can concern the whole project, such as code changes, creation or deletion of new files or folders, etc., and the command does not save them directly in the local or remote repository, but prepares them by adding them to a "staging area", i.e. a sort of "temporary area". Once you add your changes to this area, you can commit.
To add specific files to the staging area we use the following command:
git add nome_file
To add all project files (new or modified) to the staging area:
git add .
it is recommended to use the git add command selectively, adding only those files that have been changed or added and that need to be included in the next commit as they are part of the same set of project changes.
The .gitignore file
To exclude files and folders contained in the project from the action of git add , we have to create a new file called .gitignore and insert everything we don't want to include in the repository, such as JSON files containing passwords, virtual environment folders, cache files etc. Files listed in .gitignore will not be synced to the remote repository.
In this this GitHub repo you can find a collection of .gitignore templates to insert in your projects based on the programming language you use: for example this is the one for Python, therefore set to exclude files and folders common to projects created with this language:
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class
# C extensions
*.so
# Distribution / packaging
.Python
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
wheels/
share/python-wheels/
*.egg-info/
.installed.cfg
*.egg
MANIFEST
# PyInstaller
# Usually these files are written by a python script from a template
# before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec
# Installer logs
pip-log.txt
pip-delete-this-directory.txt
# Unit test / coverage reports
htmlcov/
.tox/
.nox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
*.py,cover
.hypothesis/
.pytest_cache/
cover/
# Translations
*.mo
*pot
# Django stuff:
*.log
local_settings.py
db.sqlite3
db.sqlite3-journal
# Flask stuff:
instance/
.webassets-cache
# Scrapy stuff:
.scrapy
# Sphinx documentation
docs/_build/
# PyBuilder
.pybuilder/
target/
# Jupyter Notebook
.ipynb_checkpoints
# IPython
profile_default/
ipython_config.py
# pyenv
# For a library or package, you might want to ignore these files since the code is
# intended to run in multiple environments; otherwise, check them in:
# .python-version
# pipenv
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
# However, in case of collaboration, if having platform-specific dependencies or dependencies
# having no cross-platform support, pipenv may install dependencies that don't work, or not
# install all needed dependencies.
#Pipfile.lock
# poetry
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
# This is especially recommended for binary packages to ensure reproducibility, and is more
# commonly ignored for libraries.
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
#poetry.lock
# pdm
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
#pdm.lock
# pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
# in version control.
# https://pdm.fming.dev/#use-with-ide
.pdm.toml
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
__pypackages__/
# Celery stuff
celerybeat-schedule
celerybeat.pid
# SageMath parsed files
*.sage.py
# Environments
.env
.venv
env/
venv/
ENV/
env.bak/
venv.bak/
# Spyder project settings
.spyderproject
.spyproject
# Rope project settings
.ropeproject
# mkdocs documentation
/site
# mypy
.mypy_cache/
.dmypy.json
dmypy.json
# Pyre type checker
.pyre/
# pytype static type analyzer
.pytype/
# Cython debug symbols
cython_debug/
# PyCharm
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
# and can be added to the global gitignore or merged into this file. For a more nuclear
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
#.idea/
By creating a new repository directly from GitHub as we will see at the end of the article, you will have the possibility to choose an appropriate .gitignore file.
How to remove a file from the staging area
Sometimes you add a file with git add and then realize you don't want to include it in the commit. In that case we can use the git reset command to undo the addition of the specified file:
git reset nome_file
The git reset command has other uses as well, but in this case it does the exact opposite of what git add does . If we use the command without any optional parameters, all files that are currently in the staging area (the temporary area) will be removed from it. However, any changes made to the project or to the contents of the files will not be undone and can therefore be "re-added" with git add.
The git commit command
One of the most useful and important features of Git are commits . A commit represents a single change made to the project content. Typically these changes will be textual such as updating the source code of a .py or .js file, but they can also represent the addition or removal of other types of files such as images on a website. When you create a commit in Git , you select the files you want to include and add a message describing the changes you've made.
git commit -m "message"
example:
When the commit is created, Git creates a unique hash to identify it through the SHA algorithm , which associates a 40-character string with each commit in the repository.
How to write the commit message
Carefully choosing the message that describes the commit is essential for the management of the repository, both for us who write it, and for those who are possibly working on our own project and will have to read it. A precise and clear commit message makes it easy to understand the changes made and why they were made - this could prove incredibly useful not only when collaborating with others, but also when debugging our own code! But how do you write a good commit message?
Preferably in English : it's the predominant language in the world and it's easier to make yourself understood by everyone, especially if you collaborate on a project with people from different parts of the world.
It should start with an explanatory keyword that describes the type of change you are implementing. Some of the most used keywords are: Add, Merge, Fix, Remove, Update, Change, Refactor, Hide, Test, etc.
The present indicative must be used : for example we write “Add” and not “Added”.
Must be specific - It should describe exactly what changes you've made, and should never be generic or vague like "Miscellaneous Updates". For example we could write a commit like "ADD get_URL method to View class", or "Add the get_URL method to the View class".
It should be concise and to the point, avoiding unnecessary information or irrelevant details.
However, keep in mind that each open source project or work team could have reference guidelines that always take precedence.
The git log command
To view the commit history of a repository, we can go to the hosting site that hosts it, such as GitHub , or directly use the git log command :
git log
The command will show us in the terminal a list of the commits in the order they were made, together with related metadata such as author, date, commit message and hash:
The git push command
The git push command is used to push local commits to a remote repository . With this command we update the files contained in the repository with the changes we have made locally and we ensure that the other team members with whom we are possibly collaborating can access them and integrate them with their version of the code.
If we do not use this command, the changes made will be kept only in the local repository and will not be accessible remotely.
git push
When running the git push command on a repository that is not owned by the user, it must have permissions to access: if we run it without having write permissions, the git push command will return an error and will not push the changes. In this case, it may be necessary to fork the repository and submit a pull request to request (or suggest!) the integration of the changes: we will see shortly what this means.
The git pull command
The git pull command performs the opposite operation of git push : it is used to fetch the changes from the remote repository and integrate them with the local repository in order to have the latest version of the project.
git pull
If we don't use the command when working on a project collaboratively with others, the local repo may become outdated relative to the remote one and conflicting changes may occur.
What is a pull request?
When we want to contribute to a repository that we don't own, we can fork the repository, make the necessary changes, and then send a pull request to the owner of the original repository. The latter can then examine the changes, discuss any problems and decide whether to accept or not: if the pull request is accepted, the changes are integrated into the original repository.
The git fetch command
We have seen that the git pull command synchronizes the remote repository with the one we have locally. If we just want to download and view the changes without applying them automatically , we use the git fetch command :
git fetch
If we accept the changes and want to apply them to the local copy we can simply use the git pull command .
The git clone command and forks
The git clone command allows you to download the entire repository from the remote repository and create a local copy on your computer . This copy will include all files, commit history, and configuration information at any point in the project's development. You can use the git clone command both on your own repositories and on other developers' public ones.
When using the command you need to specify the URL of the remote repository you want to clone. For example, let's create a local copy of the "jerry" repository from the remote one on GitHub :
git clone https://github.com/username/jerry.git
On GitHub we can obtain the command described above automatically, by clicking on the appropriate green button.
When you clone a repository, a link is created between the local and the remote repository, identified by the name origin (in Italian "origin"), which is the term used to refer to the remote repository from which the local repository was cloned. You will be able to browse the project's code and files, as well as run the code, as if you were on the developer's computer.
The Forks
If you think that a public project developed by other developers is particularly interesting, and you intend to make personal changes and then want to save them, for example to ensure that the code of an open source project is adapted to your specific use case, you can create a fork (a "fork") of the project. The fork is an independent copy of the repository and will be combined with your GitHub profile, from where you can access it.
The user who forked the repository can now work on his copy, create new branches and make changes to them without having to notify the creators of the original project.
If you intend to share your changes with the original project so that they are merged into the main branch of the forked project (the main branch) you can send a pull request to the creators of the original project. With this process it is possible to collaborate in teams for even very large development projects:
Fork the project on GitHub
Clone the fork repo to your computer
Create a branch to make changes to
Commit the changes to the branch
Publish the changes to your fork's branch via push
Open a pull request
Note: It is important to always follow specific recommendations and guidelines for each project before proposing changes to add to the original repo.
The git branch and git checkout commands
Like commits, branches are another fundamental concept of git. A branch (in Italian "ramo") is a separate development line within a repository and allows you to make changes without affecting the main code, which is generally considered the most stable and suitable for use in production.
When working on a complex project, several features or bug fixes may be developed simultaneously by multiple developers. To avoid interfering with the work of others or to safely test possible updates, it is possible to create a branch separate from the main branch for each new feature or bug fix: in this way all the changes made to that branch are separate from those made to the others. main or master are the default names given to the main branch of projects.
For example, to create a separate branch to implement feature-X, we write:
git branch feature-X
After using the git branch command as shown above, trying to issue the git status command (which we will see in detail later) we will realize that we are still in the main branch main.
To move to this new branch we can use the git checkout command :
git checkout feature-X
By issuing the git status command we will now see that you are on the feature-X branch, and any commits will now be matched to this separate development line.
This way, developers can work independently on their development branches without interfering with each other's work. Once the work is complete, the development branch can be merged into the main branch via the git merge command .
The git merge command
To combine the changes of two branches into one , we use the command merge.
To perform a merge, we need to tell the command which branch we want to merge with the one we're currently working on. For example if we are in main , we can merge the feature-X branch by sending the command:
git merge feature-X
Typically you develop the changes in an isolated branch and when you get to a point where you feel satisfied with the written code, because it is functional and stable, you move to the main branch and do the merge.
Git will try to merge your changes automatically, thus implicitly expecting a certain level of discipline and rigor in the development process. In case of conflicts that may arise however, because perhaps two branches are working on the same files at the same time, Git prompts the user to resolve them manually by choosing which change to keep and which to discard.
The git status command
We can view the status of the Git repository using the git status command , which allows us to access various information about our repository, including:
The current branch and the most recent commit.
Files that have been modified but not yet added to the staging area.
Files that have been added to the staging area, but not yet committed.
Files that have been deleted from the working directory, but have not yet been deleted from the staging area.
The command is essential for tracking changes made to files in the repository and for checking the current state of the branch. For example, if we haven't changed any files, git status will only tell us which branch we are in:
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
If, on the other hand, we modify a file, it will tell us information about the file and about the modification:
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")
The git revert command
We have said that one of the greatest conveniences of Git is being able to undo the changes previously made to a repository: to do this, we use the git revert command . The command does not delete the previous commit , but creates a new one which undoes the changes made: the commit history remains intact and the original commit remains in the repository.
To use the git revert command , we need to specify the hash of the commit we want to undo. For example, to uncommit with the hash xyzt421 , we run the following command:
git revert
Git will open a text file to insert a commit message, and when saved, it will create a new commit that undoes the changes made in the specified commit.
The git reset command
When we talked about the git add command , we saw that the git reset command is used to remove files from the staging area . This command also has several other uses: we can use it to undo the last commits we've already pushed, move a branch to a previous commit, restore a file, and much more. For example, to undo the last commit made in the current branch while keeping the changes made to the files, we can use git reset as follows:
git reset HEAD~1
This way we can make corrections to the undone commit and then make a new commit with the corrected changes.
The HEAD file
In the commands and in the log we have seen that the term HEAD is used : it is a file contained in the .git repository folder which represents a reference to the branch we are currently in. If we are in the main branch, this will be the contents of HEAD:
ref: refs/heads/main
If we change branches, the reference will change:
ref: refs/heads/other-branch
Examples of using Git
Now let's look at a number of common uses of Git and GitHub . We will find ourselves doing these operations very often if we decide to use Git as a version control system:
Create a new repository on GitHub
Make a commit
Download changes from a remote repository
Create a new branch
Merge a branch
Create a new repository on GitHub
Go to the GitHub site and click on the + in the navigation bar at the top right of the page and select the "New Repository" item. We choose a name for our repo (in this case I called it dzoRepo ) and whether to make it public or private.
As you can see, we also have the option to automatically generate a README.md file and a .gitignore file compatible with the type of project we are developing. They also have the option to choose an open source license type .
Once the parameters we deem most appropriate have been set, click on the "Create repository" button.
GitHub at this point will show a screen with various commands. We can simply clone the repository, set it up as a remote host for a repository already on our system, and more.
how-to-use-git-github-24
The most common usage workflow involves using the git clone command on the url of the newly created repo on GitHub. Once the project has been cloned on our computer we can start writing code with a progression of commits, which can then also be uploaded to GitHub as we make new changes.
However, if you're new to using git, you likely have more or less developed draft files that you can use as a starting point for your new project, and which you need to add to your project.
Let's assume we have a simple script called factorial.py containing a function that find the factorial of a number :
import math
def factorial(n):
if n == 0:
return 1
else:
return n * factorial(n-1)
n=10
print(factorial(n))
Since we already have files that we know we will certainly need, before issuing the git clone command on our repo, starting from the same screen with all the commands shown by GitHub that we have just seen, click on "upload an existing file" to access to a file upload screen with drag and drop.
Drag and drop the factorial.py file to upload. Then click the green "commit changes" button.
Screenshot of GitHub File Upload
Now we just have to download the correctly initialized repo, open the folder just downloaded in a text editor, and start developing:
Make a commit
git clone https://github.com/dzosoft/dzoRepo.git
Let's modify the local copy of our factorial.py file somehow. I added a line of code to ask for a number as input from the user.
n=int(input("Input a number to compute the factiorial : "))
Now, if we issue the git status command from inside the repo folder, the output will tell us that the file has been modified but has not yet been added to the staging area:
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git restore ..." to discard changes in working directory)
modified: factorial.py
no changes added to commit (use "git add" and/or "git commit -a")
So let's add our file to the staging area with the git add command:
git add factorial.py
Now the git status command will tell us that the file has been added to the staging area and is ready for commit:
On branch main
Your branch is up to date with 'origin/main'.
Changes to be committed:
(use "git restore --staged ..." to unstage)
modified: factorial.py
If we are happy with the changes we have made we can then commit. We use the git commit command adding the “ -m ” flag, and write the commit message directly from the command line. Remember that the commit message should always describe the changes made in a short but effective way.
git commit -m "Add user input for three numbers using map function"
To update the remote repository with the changes we have made, we issue the git push command . Returning to GitHub and exploring the repository we will now notice that the changes have also been saved remotely!
Download changes from a remote repository
Given what we have said so far especially regarding collaborative development, it is likely to think that the GitHub repository could be more up-to-date than the one present on our computer. Now we will see how to download the changes from the remote repository and apply them to the local one, creating a new Markdown file directly from GitHub as an example.
Each repository should have a README.md file inside: its main purpose is to describe the project, its features and provide instructions for installing the software. The file will automatically show up on the repository home page, and anyone with access will be able to read it.
We create the README.md file directly from GitHub by pressing the button labeled "Add File" within the repository, we will find ourselves in front of this screen:
We write the commit message and press the green key: now on the remote repo there is a file that we don't have locally! What to do to be able to have it locally?
As you may have guessed at this point, we issue the git pull command : the file will be downloaded and we will be synchronized with the remote repo.
Let's edit README.md again from the GitHub interface by opening it and pressing on the pencil:
We modify the file in any way and describe our modification in the commit message.
Now that we know we want to integrate the changes made on GitHub, if we issue the git pull command as we have already seen in the previous examples, our local repo will be synchronized with the remote one.
Create a new branch
Let's create a new branch for our dzoRepo repository . Let's call it “chatgpt-implementation” because the functionality we want to implement in the future will be to use the chatGPT:
git branch chatgpt-implementation
The changes we have made so far have all been uploaded to the main branch, i.e. to main. Let's move to the branch we just created like this:
git checkout chatgpt-implementation
Alternatively we can create a new branch and automatically switch to it with a single command by adding the -b flag:
git checkout -b chatgpt-implementation
To publish the branch in the remote repo we issue the following command:
git push origin chatgpt-implementation
Now we can work on the branch without our changes affecting main. Let's modify our code, for example by inserting an import statement. If we send the commit to the remote repository, opening it we will see this screen:
So our change was saved to the branch we created in the repository remotely as well. Now we can merge and integrate the change into the main branch directly from here by pressing the green "Compare & pull request" button or from the terminal, let's see how.
Merge a branch
Let's make another change to our code we add some comments. We write an appropriate commit message and push our changes, in my case it will be “Remove type annotations from function arguments”.
Now let's try to merge our branch with main. Since we are on the branch we want to merge, let's switch to the main branch and then issue the merge command.
git checkout main
git merge chatgpt-implementation
Finally, we send the command to synchronize the commits on the local branch with the remote one:
git push
Now the changes made to the branch will be integrated into the main branch!
With this article we have only begun to explore the features of Git : they are really many and for a complete overview you can consult the documentation.
With what we have seen together you should have got an idea of the functionality of Git and GitHub , but you will discover many things as you use them for your projects. If you want, you can also find a super in-depth guide on the official website , complete with videos in English!
EN 
Español - ES 
Français - FR 
package manager :
