Sign In
Sign In

How to Install and Use Gitea

How to Install and Use Gitea
Hostman Team
Technical writer
Git
28.06.2024
Reading time: 13 min

Gitea is a lightweight and accessible version control system based on Git, designed for ease and efficiency for both individual users and teams. The platform is open source, making it freely available for use and modification. The main advantage of Gitea is that it can be deployed on a user's private server, ensuring complete control over data and configuration.

Gitea offers all the essential Git features, such as branching, merging, and tagging, as well as additional project management conveniences, including a task tracking system, wiki pages, and code review tools. This makes it an ideal solution for development teams who want to collaborate on projects in an isolated and secure environment.

As more organizations and individuals recognize the importance of digital security and autonomy, Gitea stands out as a reliable and convenient solution for self-managing data and projects. An active community and extensive documentation further simplify the adoption and use of this system in various contexts.

Version control systems are traditionally associated with software development, but their potential applications are much broader. For non-programmers, they can become powerful tools for solving diverse data management and project coordination tasks.

One prominent example is using Gitea for synchronizing notes. For instance, users of note-taking applications like Obsidian can use Gitea to version their notes. This allows tracking changes, reverting to previous versions, and even collaborating on notes with other users.

Another common scenario is using Gitea as a tool for synchronizing and versioning passwords with a password manager like Pass. This approach increases password management security by providing change history, synchronization between devices, and the ability to restore previous states.

System administrators and Linux enthusiasts will also find Gitea particularly useful. For them, the system can serve as a reliable repository for system and application configuration files. In case of need, it's easy to track changes made to configuration files and, if necessary, revert to an earlier version. This is especially important when changes to the configuration can affect system stability.

Additionally, Gitea can serve to manage content and project documentation. For example, organizations can use built-in wikis to create and store technical manuals, instructions, and other documents, which is especially useful in conditions of frequent changes and the need to provide access to current information.

Gitea is supported by an active community of developers and users who regularly update and supplement the documentation, making the system accessible to both beginners and professionals. Users can seek help through GitHub, specialized forums, and chats where they can ask questions, share experiences, or find solutions to specific problems. This ensures reliable support and constant platform development.

Alternatives and When to Choose Gitea

Choosing the right version control system depends on the specific needs of the project or organization. Gitea stands out among similar systems due to its lightness and minimal resource requirements, making it ideal for small teams or individual developers who need a simple and effective tool without complex infrastructure.

Unlike GitHub, which is a popular commercial platform, Gitea provides full control over your data since it can be deployed in your own infrastructure. This can be critically important for organizations requiring strict adherence to privacy and security policies.

GitLab, while offering extensive CI/CD capabilities, requires significantly more resources for its operation and has a complex structure, which may be excessive for small projects. Moreover, not all GitLab features are available in the free version, which can also influence the choice in favor of more accessible solutions.

Thus, if your goal is to ensure ease of management, minimize infrastructure costs, and maintain full control over the system and data, Gitea is an excellent choice.

Installation Process

Before installing Gitea itself, we will perform a series of preparatory steps.

We will use a cloud server and install Gitea on Ubuntu 22.04, but it should be noted that the Gitea installation process in other Linux distributions is not significantly different.

Creating a Cloud Server

Go to the Hostman control panel and click Create server in the Cloud Servers section. Choose Ubuntu 22.04 as the operating system. Select the region and the minimum available server configuration. Leave the default settings for the network: create a public IP and no private network.

For increased reliability, consider enabling the backup service. This service can be important if additional data redundancy is needed. We will look at the process of creating backups manually, but a full server backup can be useful for ensuring redundancy.

Specify the SSH key, set the server name, and complete the order by clicking the Order button.

After creating the server, connect to it via SSH and update the system with the following commands:

apt update
apt upgrade

These commands will update the system to the latest available package versions.

Setting Up the Database

Before starting the installation, it is necessary to prepare the database that will be used to store all information related to the version control system. We will use MariaDB, a popular database management system known for its performance and compatibility with MySQL.

Installing MariaDB

First, install MariaDB on your server with the command:

apt install mariadb-server

This command will install MariaDB along with all necessary dependencies.

Securing MariaDB

After installation, run the mysql_secure_installation script, which will help to configure security settings:

  • set a password for the root user,

  • remove anonymous users,

  • restrict remote database access,

  • remove the test database.

This will improve the security of your database server:

mysql_secure_installation

Follow the on-screen prompts to complete the setup.

Creating a User and Database

Next, log in to the MariaDB console and create a user and database that will be used by the system:

mysql -u root -p

After logging in, execute the following commands:

CREATE USER 'hostmangitea'@'%' IDENTIFIED BY 'secretpass';

This command creates a new database user. Here 'hostmangitea'@'%' specifies the username and the host from which they can connect. The % symbol means that the user can connect from any host. The part IDENTIFIED BY 'secretpass' sets the password for this user. It is important to choose a reliable and secure password.

CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';

This command creates a new database named giteadb. It also specifies that the database will use UTF-8 for storing characters, which is suitable for texts in any language.

GRANT ALL PRIVILEGES ON giteadb.* TO 'hostmangitea';

This command grants the hostmangitea user all rights to work with the giteadb database. This includes read, write, and modify data rights, which are necessary for the full operation of the application.

FLUSH PRIVILEGES;

This command applies all privilege changes made. It updates the privileges so that the new settings take effect immediately without restarting the server. To exit mysql, press CTRL+D.

Installing Gitea

To install Gitea on your server, follow these steps.

Download and Install the Executable File

Download the latest stable version of Gitea from the official website:

wget -O gitea https://dl.gitea.io/gitea/1.22.0/gitea-1.22.0-linux-amd64

You can see the list of all available versions on the Gitea website.

Make the downloaded file executable:

chmod +x gitea

Check the Installed Version of Git

Make sure Git is installed on your server, as it is necessary for Gitea to work:

git --version

Create a System User

Create a separate user under which Gitea will run:

adduser \
   --system \
   --shell /bin/bash \
   --gecos 'Git Version Control' \
   --group \
   --disabled-password \
   --home /home/git \
 git

Set Up Directory Structure

Create the necessary directories for storing data, configurations, and logs:

mkdir -p /var/lib/gitea/{custom,data,log}
chown -R git:git /var/lib/gitea/
chmod -R 750 /var/lib/gitea/
mkdir /etc/gitea
chown root:git /etc/gitea
chmod 770 /etc/gitea

Set the Working Directory and Copying the File

Set the environment variable for the working directory and copy the executable file to the system directory:

export GITEA_WORK_DIR=/var/lib/gitea/
cp gitea /usr/local/bin/gitea

Creating and Configuring the Service for systemd

Create a service file for systemd so that Gitea starts automatically on system startup:

nano /etc/systemd/system/gitea.service

Insert the following configuration file in the editor window:

[Unit]
Description=MyGitea
After=network.target
Wants=mariadb.service
After=mariadb.service

[Service]
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea

[Install]
WantedBy=multi-user.target

Then enable and start the service:

systemctl enable gitea
systemctl start gitea

Check that the service is running:

systemctl status gitea

Completing the Installation via the Web Interface

Now you can go to the IP address of your server and open the setup page in a browser: http://<your_server_ip>:3000. You will be greeted by the installation wizard. At this stage, you will need to configure the database connection and create an administrator account.

Database Configuration

  1. In the Database Type field, select MySQL, corresponding to your database type.

  2. In the Host field, leave the default value.

  3. Enter the database username in the Username field — in your case, it is hostmangitea.

  4. Enter the password you set when creating the database user in the Password field.

  5. In the Database Name field, specify the name of your database, which you set earlier, giteadb.

General Settings

In the General Settings section, you can leave the default values. These settings include path and base URL configurations, which can be changed later if necessary.

Creating an Administrator Account

In the Administrator Account Settings section, you need to create an administrator account by specifying the desired username, password, and contact email. This account will be used to log in to the system and manage Gitea.

Completing the Installation

After filling in all the necessary information, click the Install Gitea button. The installation process will begin, and after completion, you will be able to log into the system using the created administrator account.

Setting Up Nginx and SSL for Your Domain

After installation, to ensure security and proper operation on your own domain, it is recommended to configure the Nginx web server and install an SSL certificate. This will protect the data and ensure encryption during transmission over the internet.

Installing and Configuring Nginx

Install Nginx on your server:

sudo apt install nginx

Create a configuration file for your domain in Nginx:

nano /etc/nginx/sites-available/hostmangitea.test.ru

Insert the following configuration, replacing hostmangitea.test.ru with your domain:

server {
    listen 80;
    server_name hostmangitea.test.ru;

    location / {
        client_max_body_size 512M;
        proxy_pass http://127.0.0.1:3000;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;
    }
}

Activate the new configuration by creating a symbolic link in the sites-enabled directory:

sudo ln -s /etc/nginx/sites-available/hostmangitea.test.ru /etc/nginx/sites-enabled/

Installing an SSL Certificate with Certbot

Install Certbot and its Nginx plugin:

sudo apt install certbot python3-certbot-nginx

Run Certbot to automatically install the SSL certificate for your domain:

certbot --non-interactive -m mail@example.com --agree-tos --no-eff-email --nginx -d hostmangitea.test.ru

This command will issue and configure the SSL certificate, automatically updating the Nginx configuration to use HTTPS. In the command, change mail@example.com to your email and hostmangitea.test.ru to your domain.

Restart Nginx to apply the changes:

sudo systemctl restart nginx

Now, the service is available over a secure HTTPS connection on your domain.

Additionally, you can edit the /etc/gitea/app.ini configuration file to set up the domain and access level. In the [server] section of the configuration file, change the values of SSH_DOMAIN, DOMAIN, and ROOT_URL to your domain instead of the IP address. This will correctly display links in your version control system.

In the [service] section of the /etc/gitea/app.ini file, you can set the DISABLE_REGISTRATION parameter to true to disable new user registrations. This will increase the security of your system by restricting access to selected users only.

To apply the changes, restart the service with the command:

sudo systemctl restart gitea

Security and Backup

To ensure the security of your data, configure a firewall on the server and set up a backup system.

Configuring the UFW Firewall

Properly configuring the firewall is important for securing your server. Using ufw (Uncomplicated Firewall), you can easily manage access to various ports and services. Below are the basic steps for configuring ufw:

Reset the current firewall settings:

sudo ufw reset

Deny incoming connections by default and allow outgoing:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Allow access to standard web ports and SSH:

sudo ufw allow 80
sudo ufw allow 443
sudo ufw allow 22

Deny access to your git server on ip:3000 for external connections:

sudo ufw allow from 127.0.0.1 to any port 3000
sudo ufw deny 3000

Activate and check the status of the firewall:

sudo ufw enable
sudo ufw status

Creating a Backup

Regular backups are a key aspect of maintaining data security. For Gitea, the backup process can be done as follows:

Switch to the user under which Gitea runs:

su git

Go to the directory where the backup will be created (e.g., /home/git):

cd /home/git

Run the command to create a data dump:

/usr/local/bin/gitea dump -c /etc/gitea/app.ini

This command will create an archive with the backup, including the database, configuration files, repositories, and other important data.

The created archive will contain important components such as:

  • app.ini — configuration file (if it was outside the standard custom/ folder),

  • custom/ — all custom settings if used,

  • data/ — application data including attachments and avatars,

  • repos/ — full copy of the repository directory,

  • gitea-db.sql — database dump,

  • log/ — various logs, although they are not essential for recovery.

Restoring from a Backup

To restore data from a backup, follow these steps:

Unzip the backup archive:

unzip gitea-dump-id.zip

Go to the directory with the extracted data:

cd gitea-dump-id

Now restore the main components. Configuration files:

mv app.ini /etc/gitea/conf/app.ini

Application data:

mv data/* /var/lib/gitea/data/

Logs:

mv log/* /var/lib/gitea/log/

Repositories:

mv repos/* /var/lib/gitea/gitea-repositories/

Update permissions:

chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea

Import the database dump into MySQL:

mysql --default-character-set=utf8mb4 -u$USER -p$PASS $DATABASE < gitea-db.sql

Replace $USER, $PASS, and $DATABASE with the username, password, and database name respectively.

These steps will allow you to restore all necessary information and data on your server after a failure or transfer to a new server.

Conclusion

In this article, we thoroughly reviewed the process of installing Gitea on your server as well as configuring it, starting from the basic installation, going through security and backup configuration, and ending with integration with external services for application deployment. Now you have the knowledge on how to effectively use version control systems to manage your code versions and automate development. The platform provides a reliable and scalable foundation, allowing you to significantly increase development productivity and enhance control over project changes.

Git
28.06.2024
Reading time: 13 min

Similar

Microservices

Sending and Applying Git Patches via Email – No GitHub Needed

Git today is the most widespread and popular version control system. Probably 99% of all current projects use Git, from the Linux Kernel to simple JavaScript libraries consisting of just one file and one function. The Linux Kernel is a huge and very complex project. It involves a large number of programmers worldwide. Coordinating changes in this project would be simply impossible without an effective solution that allows this entire community to work independently of one another. Now, this seems like a simple and obvious solution. However, the path to it was long and thorny. A Brief Retrospective 1998 was an important year for Linux. Large vendors took notice of the project, and more and more developers joined. At that time, the project followed a fairly simple model for changes: developers would send their patches to Linus Torvalds, who decided whether to include the code or not. Torvalds liked this model because it gave him control over all changes. The patch mechanism was used back when code trees were small and computers were very large. A patch literally was a set of instructions on punch cards telling what and how to replace in a stack of these media to get a new program version. Punch tapes were literally cut into pieces and glued together in a specific way to introduce changes to the program code of that time.   In general terms, a set of patches is a set of instructions that allow editing (semi- or fully automatically) the source program to get a new version. A patch set is always smaller than the full code version. This turned patches into a convenient interface for transferring changes and collaborative programming. Problems arose when the developer community began to grow. Linus Torvalds became a "bottleneck"; the number of patches grew, and the time to review them increased. Developers began using the CVS version control system to ease collaboration. Of course, this went against Torvalds' original policy on Linux kernel changes. He disliked the existence of parallel project branches with their own workflow. On the other hand, developers felt frustrated sending patches to Torvalds, who physically could not review, accept, request fixes, or reject them in a timely manner. Developers complained they had to send multiple emails to get the "benevolent dictator's" attention. The Emergence of Git The solution was to use a decentralized proprietary version control system called BitKeeper. The project used this software for a long time, but eventually, relations between the company developing BitKeeper and the Linux kernel developers soured. There was an amusing paradox: Linux Kernel is an open and free product licensed under the GNU General Public License (GPL). The main GPL principle is that anyone can freely use, distribute, and modify software released under this license, but all modifications must also be released under GPL. BitKeeper, however, was a fully closed proprietary commercial product owned entirely by its company.   Thus, the open and free project used a closed, non-free technology for coordinating development and versioning. Sooner or later, this fragile balance was going to break — and it did. This made using BitKeeper impossible. Torvalds rejected using Subversion and proposed Monotone instead. However, Monotone was unbearably slow. Eventually, Torvalds began writing his own version control system from scratch in C. Thus, Git was born. The new VCS was far from perfect but was positively received by the developer community and quickly gained the necessary tools. The new version control system rapidly gained popularity, and GitHub turned Git into the dominant solution for source code management in both open and commercial projects. Dominant... Indeed, any project, whether small or large (with thousands of contributors), is likely to be registered and hosted on GitHub. Even projects that don't use Git internally (like FreeBSD or OpenBSD) have read-only copies on GitHub. GitHub or Not GitHub? New developers (and not only them) tend to believe that without GitHub, project development and management are impossible. So, when you join a project as a developer (freelancer or FOSS contributor), you’ll be added to the team on this platform. Even if there are only two, three, or four of you... Even if the project consists of just a few dozen source files. GitHub everywhere. Is this good? It’s hard to answer simply yes or no. Certainly, GitHub has many useful tools; it’s convenient, fast, and reliable. Developers feel comfortable there, like in well-worn jeans. However, one should not forget that it’s a paid service managed by the well-known corporation Microsoft. Like any commercial product, GitHub is primarily focused on profit. If, for some reason, your project starts to interfere with that (damaging the platform’s image, etc.), your access will be instantly cut off. Recall the disputes GitHub had with the YouTube Downloader team, whose repositories were blocked, closed, and deleted simply because the RIAA demanded that GitHub restrict access to allegedly copyright-infringing software. This caused some (not a small number) teams to leave GitHub and switch to alternatives like GitLab or Gitea. In summary, setting aside moral and legal aspects, we see a contradiction: Git was designed as a decentralized version control system (unlike Subversion, for example), yet GitHub, which uses Git, enforces centralized management. Moreover, the developer effectively owns nothing; everything belongs to the "managing company." Is there life outside comfort? Can you use this great VCS without a third-party service? Can you accept patches without GitHub and send them to your team for review? Despite GitHub’s strong influence, Git’s architecture remains almost unchanged — it’s still a decentralized version control system. Git imposes absolutely no requirements on the exchange environment. You can use ordinary files (transfer them any way you want, even by copying to external media), upload patches to an FTP server, use SSH, or even Git’s built-in exchange protocol. This is very convenient. Recall the start of this article: Linus Torvalds accepted patches without GitHub (which didn’t exist then) by email and posted results on FTP servers. Sending Patches by Email Now, let's get to the main topic. Suppose we are a small, brave team that wants to be independent from anyone or anything. We have some money to buy a domain, VPS, and corporate email to exchange information and, of course, send and receive patches by email. Let's list tasks to build the necessary infrastructure for our project: Buy a domain. Buy corporate email and link it to our domain. Create mailboxes. Is it mandatory to buy a domain and corporate email? Not at all! You can use free mailboxes without a domain or purchase a domain later when needed. Everything depends on project requirements. However, from the early stages, the project may need a website, messaging (email), file exchange, and deployment infrastructure. You can buy these separately or combine them under one account for your project.  Suppose we are developing a web app and need infrastructure. After buying a domain and setting up DNS, we register as many mailboxes as needed. After creating mailboxes, we must configure access to them in mail clients and Git. Setting Up Git to Send and Receive Patches via Email It all starts with installing a special Git extension package called git-email. This is done using the package manager of your operating system or its distribution. For example: Fedora: sudo dnf install git-email Ubuntu / Debian: sudo apt-get install git-email On Windows, git-email is included in the standard Git installation package. Next step — configuration. In your OS terminal, run: git config --global --edit This will open your favorite terminal (or other) text editor, where you need to add the following lines to your Git configuration (the example uses test credentials; you should use your own!): [user] name = Maria Ortega email = zerozero@hostman-example.com [sendemail] smtpserver = smtp.hostman.com smtpuser = zerozero@hostman.site smtpencryption = ssl smtpserverport = 465 The parameter smtpencryption can be set to either ssl or tls. The second mode uses STARTTLS to initiate communication over an encrypted channel, while the first mode encrypts the connection immediately after it is established. The choice of mode and port depends on your email provider’s requirements. The [user] section is mandatory. Here, you identify yourself, and this information will appear in all patches and commits made by you. For stricter identification of patches and commits, Git supports signing sent information with GPG keys — but that’s another story. Now that we’ve set up Git to send patches via email let’s try it out. First, we need to clone a copy of the current working repository version. There are various ways to do this, which we’ll discuss at the end of the article. After cloning, make some changes to your project. Create a file named log_stderr.go: package main import ( "fmt" "time" "os" ) func logStderr(message string, args ...interface{}) { x := time.Now() fmt.Fprint(os.Stderr, x.Format(time.RFC822)) fmt.Fprint(os.Stderr, " - ") fmt.Fprintf(os.Stderr, message, args...) } Stage and commit the changes: git add log_stderr.go git commit -m "log into stderr func" Now send your patch to the project lead for review: git send-email --to="project-boss@hostman-example.com" HEAD^ The --to argument can accept multiple addresses separated by commas. This way, you can send your patch to all project members. You can also use --cc (carbon copy) to send the patch to additional email addresses separated by commas. This is useful when you want to send patches for review to the entire team or specific interested parties. To avoid specifying recipients every time on the command line, you can add them to your Git config: git config sendemail.to "project-boss@hostman-example.com" git config sendemail.cc "user1@email.tld","user2@email.tld",…,"userN@email.tld" After that, just run: git send-email HEAD^ …And your patch will be sent to the configured addresses. In this example, we sent the current changes from our working copy (HEAD^). You can send any changes, for example, two commits before the current one, or by commit hash. More details are in the Git documentation. Git will generate the patch and try to send it via the SMTP server specified in the config. If the SMTP server requires authentication, you’ll need to enter your password. If you send many patches, this can be tedious. You can save the password in the config, but note it will be stored unencrypted: git config --global sendemail.smtpPass 'your password' A better option might be to configure Git to cache your password for some time: git config --global credential.helper 'cache --timeout 3600' More advanced solutions can use password managers and the git-credential extension, but we won’t cover that here. Receiving and Integrating Patches Your team members receive your patch as a plain text email message, and they can review it — and, imagine that, reject your changes with requests to “fix” or “rewrite.” This is natural and the core of collaborative software development. The freedom and manual patch management are what attract developers to create their own information exchange solutions. What if You Are Asked to Fix Your Patch? Suppose developers ask to reduce calls to the Fprintf function and add a logging severity level. The updated code will look like this: package main import ( "fmt" "time" "os" ) type LogSeverity string const ( ERR LogSeverity = "ERROR" WARN LogSeverity = "WARN" INFO LogSeverity = "INFO" DEBUG LogSeverity = "DEBUG" ) func LogStderr(message string, severity LogSeverity, args ...interface{}) { x := time.Now() fmt.Fprintf(os.Stderr, "%s - %s - ", x.Format(time.RFC822), severity) fmt.Fprintf(os.Stderr, message, args...) fmt.Fprint(os.Stderr, "\n") } Since we’re fixing our previous patch and haven’t released any newer patches, we can simply amend the current commit: git commit -a --amend Now send the patch again, remembering we already configured the recipients: git send-email --annotate -v2 HEAD^ The -v2 flag means this is the second version of the patch. If you need another fix, use -v3, and so on. The --annotate flag allows you to add comments to your email message. Git will open a text editor showing something like: Subject: [PATCH v2] Logging function to stderr --- Added log level, reduced fmt.Fprintf calls Add your notes, save, and close the editor; the patch will then be sent again to the recipients. Always add annotations to your patches — it makes life easier for both you and your colleagues. Typing --annotate every time can get tedious, so you can automate it: git config --global sendemail.annotate yes How to Receive and Apply Patches? Receiving patches is a bit trickier. Git sends specially formatted patches in plain text email messages. There can be many such patches, and Git does not restrict the transport method (email, FTP, etc.), so it doesn’t handle how to receive patches — that’s up to the developer. Just use your mail client’s capabilities. After receiving approved annotated patches, save one or more email messages containing patches in an mbox file (Unix mailbox format). This format stores one or more email messages in a single file. Then run: git am <path_to_patches.mbox> All patches will be incorporated into your working copy. You can continue working and impressing your team. Email-based Git workflows can be as simple or sophisticated as you want. The main thing is that it suits the team and does not create unnecessary inconvenience. It seems there is nothing simpler, neater, or more elegant than working with Git over email. However, there is one major problem: distributing the working copy to new developers joining the project. If the project is large and has a rich history, the repository size might be many megabytes or even gigabytes. Sending that over email is impossible — it’s simply not designed for that. How to Provide a Newcomer with the Entire Project History? Git has an interesting feature called a bundle. It’s a snapshot of the working copy or the entire repository in a binary format of Git changes. Bundles are much more compact than a set of text patches; history and data inside the bundle are compressed, and the format allows transmitting both text and binary data. Project leads or other responsible persons can upload the current project bundle to a file-sharing service — for example, an FTP server or an S3-compatible object storage like Hostman. The newcomer downloads the project bundle and clones it: git clone project.bundle <new_place> Now <new_place> contains a new working copy ready to work with email patches. However, to be honest, bundles are somewhat of an alternative to the patch email exchange workflow described above. Collaborative work using bundles is a different story.
07 July 2025 · 12 min to read
Git

Working with Git Tags

Git has been around for almost 20 years, yet it remains the most popular distributed version control system. It is best known for GitHub, the largest remote Git repository where developers store their code, document changes, and save previous versions. To help manage versions efficiently, Git provides special markers called tags. This article will explore what Git tags are and how to use them. What Are Git Tags? To understand Git tags, let's first clarify some related concepts. Commit: A commit is a saved version of a project. Branch: A collection of commits that visually represents the history of changes in a project. Multiple branches can exist simultaneously. Now, let’s define tags. Git tags are markers used to highlight important commits. They help track version history, as responsible developers often tag each new version. Like branches, Git tags point to a specific commit, but unlike branches, they do not have a history of commits. Now, let's see how to work with Git tags—create, view, publish, replace, switch, and delete them. How to Create Git Tags Git has two main types of tags: annotated and lightweight. Each is created differently. Creating Annotated Tags Annotated tags store complete version information, including developer names, emails, and timestamps. They are created using special Git flags, -a and -m, as shown in the example below: git tag -a ver-2.5 -m "beta version 2.5" git tag Output: ver-0.1 ver-1.6 ver-2.5 git tag is the main command for working with tags. -a creates an annotated tag with a specified identifier. -m adds a message. If omitted, a text editor will open for message input. To view details of an annotated tag along with its commit, use: git show ver-2.5 Output: tag ver-2.5 Tagger: Marianne Smith <m.smith@company.com> Date: Fri Mar 28 11:02:35 2025 beta version 2.5 commit bf93b7eaa928fd77a55453118313701b04874051 Author: James Brown <j.brown@company.com> Date: Mon Jan 6 09:41:02 2025 This displays the tagger's information, the commit hash, the author, and the creation date. To verify that the tag was created successfully, use: git tag -n Creating Lightweight Tags Lightweight tags are simple pointers to commits, typically used for temporary markers. They store only the commit’s hash. Here’s how to create one: git tag ver-2.5a git tag Output: ver-0.1 ver-1.6 ver-2.5 ver-2.5a ver-2.6 To view a lightweight tag's commit information: git show ver-2.5a Output: commit bf93b7eaa928fd77a55453118313701b04874051 Author: James Brown <j.brown@company.com> Date: Mon Jan 6 09:41:02 2022 -0300 Unlike annotated tags, lightweight tags do not store additional metadata. Adding and Deleting Git Tags in Remote Repositories To push a tag to a remote repository: git push origin ver-2.5 Here, origin refers to the default remote repository. To push all tags at once: git push origin --tags To delete a tag from a remote repository: git push origin --delete ver-2.5 To delete a tag locally (not on the remote repository): git tag -d ver-2.5 Switching Between Tags To switch to a specific tag: git checkout ver-2.5 However, this detaches the HEAD pointer, meaning any subsequent changes will not be associated with any existing branch. If you make changes, create a new branch to keep them: git checkout -b new-branch Viewing a List of Git Tags To list all available tags: git tag Output: ver-0.1 ver-1.6 ver-2.5 ver-2.5a ver-2.6 To filter tags using a pattern: git tag -l *xyz* If you have tags like ver-1.6xyz, ver-2.5xyz, and ver-2.6xyz, this command will output: ver-1.6xyz ver-2.5xyz ver-2.6xyz Reassigning or Replacing Tags To update an existing tag, use the -f flag for forced replacement: git tag -a -f ver-2.5a bf93b7eaa928fd77a55453118313701b04874051 This reassigns the tag to a specific commit hash. However, this will delete the old tag information, so use it carefully. Summary Git tags make version control more flexible and manageable. The commands covered here are simple yet powerful, making them easy to learn even for beginners. 
03 April 2025 · 4 min to read
Git

How to Use GitHub Copilot with Python

GitHub Copilot is a tool that helps developers write code faster and more efficiently by providing suggestions and even entire blocks of code based on comments, variable names, function names, and more. GitHub Copilot saves time when writing standard code structures and algorithms. It is helpful for beginners just learning to develop in a new language and for experienced developers who want to avoid manually writing repetitive functions and structures. GitHub Copilot can be integrated into various development environments, including: Visual Studio Neovim VS Code JetBrains IDEs It also supports a wide range of programming languages, such as: Python JavaScript Go Java C# TypeScript C++ Ruby Rust Shell script Kotlin Swift GitHub Copilot is compatible with popular frameworks and libraries like React, AngularJS, VueJS, Spring, Django, Ruby on Rails, and more. In this tutorial, we’ll explain how to use GitHub Copilot when developing in Python and how it can help improve coding efficiency. Key Features of GitHub Copilot Autocomplete – Provides real-time code suggestions and autocompletion. Code Prediction – Predicts the next steps in your code and offers options to complete structures. Code Search – Helps find relevant code within a project using keywords or code snippets. Code Refactoring – Assists in optimizing and modifying existing code with refactoring features. GitHub Copilot is currently available as a subscription service for $10 monthly. How GitHub Copilot Works GitHub Copilot provides suggestions and autocomplete features based on user comments written in natural language and existing code. To achieve this, GitHub trained Copilot using publicly available repositories hosted on its platform. The effectiveness of Copilot depends on the availability of public repositories in a given programming language. It works well with popular languages like Python and offers reliable suggestions. However, for less common languages, its performance may be weaker, providing fewer and less accurate recommendations. Integrating GitHub Copilot with PyCharm PyCharm, a JetBrains IDE, supports GitHub Copilot. To integrate it into your project, follow these steps: Visit github.com/features/copilot and click Get started for free. Log in to GitHub or create an account.  Now, you can install the GitHub Copilot plugin in PyCharm: Open PyCharm. Go to File > Settings. Navigate to Plugins and search for GitHub Copilot. Click Install to add the plugin. After installation, open the Tools menu, find GitHub Copilot and click Login to GitHub. A window will appear with an authorization link and a special code. Follow the link, enter the code, and confirm authorization. Now, GitHub Copilot is fully integrated into your PyCharm project. How to Use GitHub Copilot Let's write a simple function to verify that we have successfully installed the GitHub Copilot plugin. For example, start typing a function to add two numbers, like: def add(a, b): As you begin typing, Copilot will suggest completing the function: Suggested code appears in gray and italicized text. To accept a suggestion, press Tab. To reject a suggestion, press Esc. Useful GitHub Copilot Shortcuts Action Windows Mac Activate inline suggestions Alt+\ Option+\ View next suggestion Alt+] Option+] View previous suggestion Alt+[ Option+[ Accept suggestion Tab Tab Reject suggestion Esc Esc Open all suggestions in a new window Ctrl+Enter Ctrl+Enter Using Copilot with Comments GitHub Copilot doesn’t just rely on function names—it also generates code based on comments. For example, if you write a function for matrix multiplication with a descriptive comment: def multiply_matrices(A, B): # Multiply matrix A and B and return the result Copilot may suggest the following: def multiply_matrices(A, B): # Multiply matrix A and B and return the result rows1 = len(A) cols1 = len(A[0]) rows2 = len(B) cols2 = len(B[0]) if cols1 != rows2: raise ValueError("The number of columns in the first matrix must be equal to the number of rows in the second matrix") result = [[0 for j in range(cols2)] for i in range(rows1)] for i in range(rows1): for j in range(cols2): for k in range(cols1): result[i][j] += A[i][k] * B[k][j] return result To verify that this function works correctly, let’s use the NumPy library: import numpy as np matrix1 = [[15,24],[12,44]] matrix2 = [[112, 22],[55,90]] m1 = np.array([[15,24],[12,44]]) m2 = np.array([[112, 22],[55,90]]) print(multiply_matrices(matrix1, matrix2),'\n') print(np.dot(m1, m2)) Output: [[3000, 2490], [3764, 4224]] [[3000 2490] [3764 4224]] As you can see, the function Copilot correctly performs matrix multiplication. Cons of Using GitHub Copilot GitHub Copilot is a very useful tool, but it has some drawbacks. Copilot Doesn't Test Its Code The code suggested by Copilot may contain errors. It does not perform self-checks, meaning developers must test the generated code themselves. Additionally, Copilot doesn’t always produce optimized code, both in terms of efficiency and structure. In summary, all Copilot-generated code must be reviewed and tested. Conflicts with IDEs Modern Integrated Development Environments (IDEs) do more than just provide a space for writing and debugging code—they also offer built-in suggestions. For example, when using a built-in function in PyCharm, the IDE provides information about its attributes. At the same time, Copilot might suggest something different, which can be confusing for the developer. Potential Copyright Issues This is a controversial aspect of using Copilot in commercial development. Since Copilot was trained on public repositories, it could theoretically suggest licensed code. This raises concerns about intellectual property rights when using Copilot-generated code in proprietary projects. Negative Impact on Developer Skills Copilot doesn’t teach developers how to write code—it writes it for them. For junior developers, it’s important to gain hands-on experience by implementing common functions and algorithms manually. Over-reliance on Copilot might slow down skill development. Conclusion GitHub Copilot is a useful tool for handling repetitive coding tasks. According to GitHub’s own research: 74% of developers reported focusing on more enjoyable aspects of their work, 88% felt more productive, 96% completed repetitive tasks faster. Copilot should be seen as an assistant—someone you can delegate tasks to while focusing on more important and complex problems. However, developers must carefully review all code generated by Copilot to ensure quality and correctness. 
24 March 2025 · 6 min to read

Do you have questions,
comments, or concerns?

Our professionals are available to assist you at any moment,
whether you need help or are just unsure of where to start.
Email us
Hostman's Support