Παραμετροποίηση του Git

Εισαγωγή

Τι είναι το Version Control System

A Version Control System (VCS) is a way to manage and track code changes. As we build an application, we add functions, change frontend features, fix bugs. We will need to edit the code many times. So we need a way to manage these changes. The tracking of every change to our code is the key point of VCS.

Workflow without Version Control

Από τα πιο γνωστά προγράμματα ελέγχου εκδόσεων πηγαίου κώδικα είναι τα εξής :

• Git
• Apache Subversion (SVN)
• Mercurial
• Bazaar

Δημοφιλία VCS

Έχοντας περιγράψει τι είναι το VCS, θα ήταν χρήσιμο να μελετήσουμε ποιο ήταν το πιο γνωστό ή πιο χρησιμοποιούμενο διαχρονικά. Για να το μελετήσω θα χρησιμοποιήσω ιστορικά δεδομένα αναζητήσεων στη μηχανή αναζήτησης της Google και πιο συγκεκριμένα από τη πλατφόρμα Google Trends που διατηρεί δεδομένα τάσεων αναζητήσεων ορισμένων όρων.

library(readr)
library(dplyr)
library(lubridate)
library(highcharter)

avgPercentageGit = trends_vcs_tidy %>% dplyr::filter(VCS == "git: (Worldwide)") %>% pull(AVG)
avgPercentageSVN = trends_vcs_tidy %>% dplyr::filter(VCS == "svn: (Worldwide)") %>% pull(AVG)

highchart() %>%
  hc_title(text = "Τάσεις στα λογισμικά διαχείρισης εκδόσεων κώδικα (VCS)") %>%
  hc_subtitle(text = "<span style='display: inline-block; align-items: center; text-align: center;'>Σύγκριση τάσεων μεταξύ του  <img height='16' style='margin: 0px 6px;' src='https://git-scm.com/images/logos/downloads/Git-Icon-1788C.png'> Git και του <img height='16' style='margin: 0px 6px;' src='https://upload.wikimedia.org/wikipedia/commons/thumb/2/22/Apache_Subversion_logo.svg/250px-Apache_Subversion_logo.svg.png '> SVN (Subversion) από το 2004 μέχρι το 2022</span>", useHTML= TRUE) %>%
  hc_caption(
    useHTML = TRUE,
    text = '<b>Πηγή: </b> <a href="https://trends.google.com/trends/" target="_blank">Google Trends</a>') %>%
  hc_plotOptions(
    series = list(
      marker = list(
        enabled = FALSE
      )
    )
  ) %>%
 hc_annotations(list(
  labels = list(
    list(
      point = list(x = 12, y = 70, xAxis = 0, yAxis = 0),
      text = "Git",
      rotation = -30,
      backgroundColor = "rgba(255,255,255,0.7)",
      borderColor = "black",
      style = list(
        fontSize = "12px"
      )
    ),
    list(
      point = list(x = 12, y = 10, xAxis = 0, yAxis = 0),
      text = "Subversion (SVN)",
      rotation = 0,
      backgroundColor = "rgba(255,255,255,0.7)",
      borderColor = "black",
      style = list(
        fontSize = "12px"
        )
    )
  )
)) %>%
  hc_xAxis(categories = unique(trends_vcs_tidy$Year)) %>%
  hc_yAxis(title = list(text = "Τάση αναζήτησης"),
           max = 90) %>%
  hc_add_series(name = "Git", data = avgPercentageGit, type = "line", color = "orange") %>%
  hc_add_series(name = "SVN", data = avgPercentageSVN, type = "line", color = "steelblue") %>%
  hc_tooltip(shared = TRUE)

Σχήμα 1: Χρονοσειρές σύγκρισης των τάσεων μεταξύ λογισμικών ελέγχου εκδόσεων κώδικα (Version Control Systems - VCS)

Το διάγραμμα Σχήμα 1 ξεκαθαρίζει ως κυρίαρχο εργαλείο για την διαχείριση των εκδόσεων (VCS) του κώδικά μας, το Git. Το Subversion (SVN) ήταν δημοιλέστερο του Git μέχρι και το 2010, ενώ από εκείνη τη χρονιά και έπειτα άρχισε και είχε πτωτική πορεία η οποία δεν έχει ανακάμψει για το προαναφερόμενο λογισμικό μέχρι και σήμερα. Σήμερα το de facto λογισμικό για τη διαχείριση του κώδικα είναι το Git και κυριαρχούν πλατφόρμες που υποστηρίζουν τη φιλοξενεία στο διαδίκτυο όπως το GitHub και το GitLab.

Πλεονεκτήματα

Για ποιο λόγο να χρησιμοποιήσω ένα τέτοιο λογισμικό;

• Εύκολη μετάβαση σε προηγούμενες εκδόσεις του κώδικα
• More productive, Time saver if a version produces error
• Enables cooperation with other developers (especially with a hosting service like GitHub).

Αδυναμίες

Ok. There are some good points. But where is the catch ?

• We are adding a new tool to our workflow (Git)
• Kind of steep learning curve.

Φιλοξενία κώδικα

We have mentioned some of the most important programs for managing the code of an application. Of course, there are not a few times when we want to save the progress of our application somewhere else to enable developers communicate their code commits to each other. The solution is some code hosting services. The best known are GitHub, GitLab and Bitbucket. Finally, in case none of the options outlined earlier satisfy us, there is also the self-host solution. For example, if I had concerns about the terms of the above services, I could host Gitea on my own server or even to rent a cloud server. That way I would have my own “GitHub”, without depending on a third party service.

Ρυθμίσεις του Git

Ορισμός ονόματος και email

Αποφάσισες να χρησιμοποιήσεις το Git, ώστε να το δοκιμάσεις σε κάποια απλά project ή απλά να κρατάς αρχείο εκδόσεων για τις εργασίες σου; Είσαι σε καλό δρόμο. Όταν χρησιμοποιήσεις το Git για πρώτη φορά θα σου ζητήσει να θέσεις ένα όνομα και ένα email. Το Git δεν θα σου επιτρέψει να καταγράψεις τη σύνθεση - έκδοση του project σου προτού τα καθορίσεις.

Terminal

git config --global user.name "YourName"
git config --global user.email your_email

Σημείωση

Αν σχεδιάζεις να φιλοξενήσεις τον κώδικά σου στο GitHub, ίσως να έχει νόημα να κρύψεις τη προσωπική σου διεύθυνση email. Σε μία τέτοια περίπτωση το GitHub προσφέρει ένα noreply email προκειμένου να μην την εκθέτεις στο διαδίκτυο. Αν επιθυμείτε, μπορείτε να διαβάσετε περισσότερα για αυτό το θέμα στον ακόλουθο σύνδεσμο.

Προτιμόμενο πρόγραμμα επεξεργασίας

Γενικότερα το GIt A part that I considered a little bit hard is editing Git commits. By default, Ubuntu has installed Vim, so this was my first editor for my commits. I think this choice is good if you are writing short commit messages or you are acquainted with Vim options/shortcuts. In case you are in a hurry, the use of an alterantive (most familiar) IDE is justified.

Terminal

git config --global core.editor "editor_name"

Most notable is Visual Studio Code, which is the most popular IDE, according to recent Stackoveflow’s survey.

Editor	Command
Atom	git config –global core.editor “atom –wait”
Visual Studio Code	git config –global core.editor “code –wait”

Προεπιλεγμένο όνομα

In October of 2020, GitHub announced that will change the default name of initial branch from master to main.

The default branch name for new repositories is now main.
GitHub.blog - October 1,2020

Therefore, it would be good to make this change in our local environment as well, as follows :

Terminal

git config --global init.defaultBranch main

Merge method

One change that is not exactly necessary but helps me is to change the defaults regarding merge. Let’s say that I want to add a new feature in my application. Most of the times I will make a branch on which I will start developing my new feature. When I implement this function and I’m ready to merge my changes into the main code there are two situations.

1. There are commits to main branch

The predefined action is to merge. The branch is visible. Our setting has not any effect on this case.

2. There are no commits to main branch

The predefined action of Git is to take the feature branch and paste it on the top of main branch. By making the setting above I am telling Git to keep the branch and react like the first case. The branch is visible again.

With simple words, I am forcing Git to keep branch, regardless of changes to main branch.

Terminal

git config --global merge.ff false

Auto-sign your commits

In a previous article we saw how to sign our commits as well as the reasons for doing so. In short, we made a PGP key which we added to our GitHub account. From that moment to sign my commits I had to write git commit -S -m "something", instead of git commit -m "something". Of course, that method is a little bit problematic. It is a little bit longer, little different in comparison to what I am used to type and most importantly I may forget some times to sign it manually. The last one happened to me A LOT. Thankfully, there is a way to be carefree about that anymore. I can set git config in a way that my commits will be signed automatically.

Προειδοποίηση

If you do not have already a GPG key, you can have a look in this guide in order to generate one. Also, depending your hosting platform for your code, you can link your GPG with your account :

• GitHub and GPG keys
  
• BitBucket and GPG keys
  
• GitLab and GPG keys

Terminal

gpg --list-secret-keys --keyid-format LONG
git config user.signingkey key_id
git config commit.gpgsign true

Check your settings

Making the above settings, we can have a summary of those with the corresponding command:

Terminal

git config --list

Here is the output on my machine :

Output of git-config command

The image above sums up the settings of Git. Although, each user has different needs and for that reason it would be good in case you want to learn more about git config to see their documentation page.

To sum up

A summary of the commands we used to configure Git :

Terminal

git config --global user.name "YourName"
git config --global user.email your_email
git config --global core.editor "editor_name"
git config --global init.defaultBranch main
git config --global merge.ff false

# Add PGP key to your commits

gpg --list-secret-keys --keyid-format LONG
git config user.signingkey key_id
git config commit.gpgsign true

# check git config settings

git config --list --show-origin

Of course you can access your git config file on your Home directory (at least on Ubuntu installation).

Προειδοποίηση

Note that the .gitconfig file, which contains our settings, may not be visible in the Home directory. In general, files whose names begin with a period are not displayed. However, if everything has been done correctly, it’s probably there. For example, in Ubuntu you should choose to show hidden files.

Ευχαριστίες

Φωτογραφία από Daniel Skovran από το Pixabay

Αναφορές

Chacon, S., & Straub, B. (2014). Pro git. Springer Nature.