Γενικά - Version Control Systems

Τί είναι ένα VCS

Ένα Version Control System (VCS) είναι ένα σύστημα που καταγράφει τις αλλαγές που πραγματοποιούνται σε κάποιο αρχείο ή σε ένα σύνολο από αρχεία στην διάρκεια του χρόνου. Επίσης μπορεί να πραγματοποιήσει ανάκληση προηγούμενων εκδόσεων του αρχείου αν αυτό απαιτηθεί. Ένα VCS σου επιτρέπει να επαναφέρεις κάποια αρχεία σε μια προηγούμενη κατάσταση, ένα ολόκληρο project σε μια προηγούμενη κατάσταση, να βλέπεις τις αλλαγές από προηγούμενες εκδόσεις, ποιος έκανε την τελευταία αλλαγή και ίσως προκάλεσε κάποια δυσλειτουργία και πολλά άλλα. Γνωστά version control systems που έχουν γνωρίσει ευρεία χρήση στο παρελθόν είναι τα Subversion, CVS, κ.α.

Local Version Control Systems

Πολλοί επιλέγουν σαν μια μέθοδο Version Control την αντιγραφή των αρχείων που θέλουν να παρακολουθήσουν σε ένα διαφορετικό φάκελο ή φακέλους (ίσως με κάποιο timestamp) στην διάρκεια του χρόνου. Αυτή η πρακτική συνηθίζεται γιατί είναι απλή αλλά είναι και επιρρεπείς σε λάθη καθώς είναι εύκολο να ξεχάσεις σε ποιο φάκελο είσαι και κατά λάθος να γράψεις στα λάθος αρχεία η να αντιγράψεις αρχεία που δεν έπρεπε. Για την αντιμετώπιση τέτοιων θεμάτων αναπτύχθηκαν τα τοπικά VCS που περιλαμβάνουν μια απλή βάση δεδομένων που καταγράφει όλες τις αλλαγές στα αρχεία που απαιτείται. Centralized Version Control Systems

Ένα ζήτημα που δεν μπορούσαν να αντιμετωπίσουν τα local VCS ήταν η ανάγκη των προγραμματιστών να συνεργαστούν για ένα project από διαφορετικά συστήματα. Έτσι αναπτύχθηκαν τα κεντρικοποιημένα VCS. Τέτοια συστήματα (όπως το CVS και το Subversion) περιλαμβάνουν ένα κεντρικό server που περιέχει όλα τα αρχεία που παρακολουθούνται καθώς και ένα αριθμό από clients που κατεβάζουν αρχεία από τον κεντρικό server για να τα επεξεργαστούν. Για πολλά χρόνια αυτή ήταν η standard μέθοδος που χρησιμοποιούσαν οι προγραμματιστές για version control.

Centralized Version Control Systems

Ένα ζήτημα που δεν μπορούσαν να αντιμετωπίσουν τα local VCS ήταν η ανάγκη των προγραμματιστών να συνεργαστούν για ένα project από διαφορετικά συστήματα. Έτσι αναπτύχθηκαν τα κεντρικοποιημένα VCS. Τέτοια συστήματα (όπως το CVS και το Subversion) περιλαμβάνουν ένα κεντρικό server που περιέχει όλα τα αρχεία που παρακολουθούνται καθώς και ένα αριθμό από clients που κατεβάζουν αρχεία από τον κεντρικό server για να τα επεξεργαστούν. Για πολλά χρόνια αυτή ήταν η standard μέθοδος που χρησιμοποιούσαν οι προγραμματιστές για version control.

Αυτή η μέθοδος είχε πολλά πλεονεκτήματα σε σχέση με τα local VCS. Για παράδειγμα όλοι ξέρουν τι αλλαγές έχει κάνει ο καθένας σε κάποιο project. Επίσης οι administrators έχουν πλήρη έλεγχο στο τι μπορεί να κάνει κάποιος και γενικά είναι πολύ πιο απλό να διαχειρίζεσαι ένα κεντρικοποιημένο VCS από το να έχει ο καθένας ένα τοπικό σύστημα στον υπολογιστή του. Παρόλα αυτά ένα τέτοιο σύστημα έχει και πολλά μειονεκτήματα. Το πιο σημαντικό είναι ότι βασίζεται σε ένα κεντρικό server που αποτελεί single point of failure. Αν για κάποιο λόγο αυτός ο server δεν είναι λειτουργικός για κάποιο διάστημα τότε για όσο διαρκεί το πρόβλημα δεν μπορούν να πραγματοποιηθούν αλλαγές από την ομάδα. Επίσης αν ο σκληρός δίσκος του server παρουσιάσει κάποια δυσλειτουργία τότε κινδυνεύει να χαθεί ολόκληρο το ιστορικό του project και όλες οι εκδόσεις που έχουν καταγραφεί.

Distributed Version Control Systems

Τα μειονεκτήματα των Centralized VCS ήρθαν να καλύψουν τα Distributed VCS. Σε τέτοια συστήματα DVCS (όπως το Git) οι clients δεν κατεβάζουν μόνο την τελευταία έκδοση των αρχείων που θέλουν να επεξεργαστούν αλλά κατεβάζουν ολόκληρο το repository με το πλήρες ιστορικό του. Έτσι οποιοσδήποτε client μπορεί να επαναφέρει πλήρως ένα repository σε περίπτωση που οποιοσδήποτε server εμφανίσει κάποια δυσλειτουργία.

Εισαγωγή στο GIT

Τι είναι το GIT

Η κύρια διαφορά του GIT από τα υπόλοιπα VCS είναι ο τρόπος που διαχειρίζεται τα δεδομένα. Τα περισσότερα συστήματα VCS αποθηκεύουν την πληροφορία σαν ένα σύνολο από αρχεία και για κάθε αρχείο αποθηκεύουν τις αλλαγές που γίνονται στην διάρκεια του χρόνου. Αντιθέτως το Git διαχειρίζεται την πληροφορία σαν ένα σύνολο από snapshots (commits) των αρχείων που παρακολουθούνται. Κάθε φορά που πρέπει να καταγράφουν αλλαγές σε κάποια αρχεία το Git παίρνει ένα snapshot από το σύνολο των αρχείων και αποθηκεύει μια αναφορά σε αυτό το snapshot. Επίσης όλες οι λειτουργίες του Git μπορούν να πραγματοποιηθούν στον τοπικό υπολογιστή καθώς έχει το πλήρες repository με το αντίστοιχο ιστορικό. Το GIT για οποιαδήποτε αλλαγή αποθηκεύει παράγει πρώτα ένα checksum με τον μηχανισμό SHA-1 hash και αυτό χρησιμοποιείται σαν αναφορά για αυτή την αλλαγή. Αυτό προσφέρει ακεραιότητα δεδομένων καθώς το Git διασφαλίζει ότι δεν μπορούν να αλλάξουν τα περιεχόμενα οποιουδήποτε αρχείου χωρίς αυτό να γίνει αντιληπτό. To Git έχει γνωρίσει μεγάλη επιτυχία και έχει γίνει το de-facto standard για distributed source control και ένα βασικό εργαλείο που πρέπει να μάθει κάποιος προκειμένουν να αρχίσει το ταξίδι του στον κόσμο του DevOps.

Συνιστούμε να επισκεφθείτε τα παρακάτω sites:

• https://git-scm.com/ - Git Website & Documentation
• https://www.freecodecamp.org/news/what-is-git-and-how-to-use-it-c341b049ae61/ - Γρήγορη εισαγωγή χωρίς να μπαίνει κανείς σε ιδιαίτερο βάθος, από τη γνωστή πλατφόρμα για μάθηση coding.

Πλατφόρμες για Git Repositories

To ίδιο το Git υπάρχει σε εκδόσεις για διάφορα λειτουργικά συστήματα ενώ συνοδεύεται και με εργαλεία όπως το Git Bash, Git Desktop, κλπ. Υπάρχουν όμως και πλατφόρμες που βασίζονται στο Git και δίνουν υπηρεσίες Online Repository, είτε στο Internet, είτε σε Enterprise Επίπεδο. Οι πιο γνωστές είναι το Github και το Gitlab. Ειδικά το Gitlab μπορεί κάποιος να το εγκαταστήσει τοπικά και σε δωρεάν έκδοση, σε γνωστά λειτουργικά συστήματα, σε Docker/Kunernetes, ακόμα και σε ένα RaspberryPi! https://about.gitlab.com/install/

GIT Basics

Οι 3 καταστάσεις του Git

Οι 3 κύριες καταστάσεις αρχείων στο Git είναι :

• Modified: Έχει γίνει αλλαγή σε κάποιο αρχείο αλλά δεν έχει γίνει commit στην βάση δεδομένων του Git.
• Staged: Έχει επιλεγεί κάποιο αρχείο από την τρέχουσα έκδοση έτσι ώστε στο επόμενο commit να αποθηκευτούν οι αλλαγές του στην επόμενη έκδοση που θα δημιουργηθεί.
• Committed: Τα δεδομένα έχουν αποθηκευτεί σωστά στην τοπική βάση δεδομένων του Git.

Τα 3 μέρη ενός Git project είναι :

• Working Directory
• Staging Area
• Git Repository

Working Directory

Είναι ένα checkout μιας έκδοσης του project. Τα αρχεία του working directory ανακτώνται από την βάση δεδομένων που βρίσκεται στο git directory έτσι ώστε να μπορούν να χρησιμοποιηθούν και να τροποποιηθούν.

Staging Area

Περιέχεται στο Git directory και αποθηκεύει την πληροφορία σχετικά με το τι θα πρέπει να καταχωρηθεί στο επόμενο commit.

Git Repository (Local)

Σε αυτό το directory το Git αποθηκεύει όλα τα metadata και την βάση δεδομένων των αλλαγών για το project. Είναι το πιο σημαντικό μέρος του Git και είναι αυτό που αντιγράφεται όταν γίνεται clone ένα απομακρυσμένο repository.

Git workflow (Local)

Το βασικό Git workflow ακολουθεί τα παρακάτω βήματα :

1. Γίνονται αλλαγές στο working directory.
2. Επιλέγονται τα αρχεία που θα γίνουν add στο staging area έτσι ώστε να γίνουν μέρος των αλλαγών που θα αποθηκευτούν στο επόμενο commit.
3. Πραγματοποιείται commit. Σε αυτό το βήμα όλα τα αρχεία που βρίσκονται στο staging area αποθηκεύονται σε ένα snapshot που καταχωρείται στο git directory.

Remote Repository

Αναφέραμε φυσικά για Distributed Version Control Systems, μιλήσαμε για πλατφόρμες για συνεργασια μέσω git, και κλωνοποίηση απομακρυσμένων (remote) repositories. Στο git υποστηρίζεται ως location και το remote repository, ή όπως αλλιώς αναφέρεται “upstream repository". Ένα remote repository μπορεί να αποτελεί το σημείο που συγκλίνουν όλες οι προσπάθειες των developers που συμμετέχουν σε ένα code project, οι οποίοι συνεργάζονται ασύγχρονα. Προφανώς η οργάνωση του remote repository γίνεται με παρόμοιο τρόπο αλλά προϋποθέτει πολλά ακόμα βήματα για να μπορεί να γίνει σωστά η ασύγχρονη αυτή συνεργασία, να ελεχθεί αν κάποιος έχει δικαίωμα ή όχι να συγχρονιστεί με τον κώδικα στο remote repository, ή και να παρέχει ενημερώσεις, και πολλά άλλα. Περισσότερα γι αυτό θα θίξουμε στους τομείς που θα αναφέρουμε για:

• Git Config
• Git Pull
• Git Push
• Git Branching

Δημιουργία Git Repository - git init

Οι πιο συνηθισμένοι τρόποι για την δημιουργία ενός Git Repository είναι :

• Μπορεί να μετατραπεί ένας φάκελος του τοπικού υπολογιστή (που δεν υπόκειται σε κάποιο version control) σε ένα Git Repository. Αυτό μπορεί να γίνει με τις παρακάτω εντολές :

Σε Windows:

$ cd C:/Users/user/my_project
$ git init

ή σε Linux:

mkdir my_project
cd myproject
git init .

Έτσι δημιουργείται ένας φάκελος .git μέσα στον φάκελο του project όπου περιέχει όλα τα απαραίτητα αρχεία του repository (και όχι μόνο όπως θα δούθμε παρακάτω..)

Αντιγραφή ενός Git Repository - git clone

• Μπορεί να αντιγραφεί ή “κλωνοποιηθεί” (clone) όπως λέμε, ένα υπάρχον Git Repository από ένα απομακρυσμένο υπολογιστή/server. Αυτό μπορεί να γίνει με την εντολή git clone . Για παράδειγμα αν θες να κάνει clone το netprog_basics repository από το CiscoDevNet στο github τότε η εντολή είναι :

$ git clone https://github.com/CiscoDevNet/netprog_basics.git

Αυτή η εντολή θα δημιουργήσει ένα φάκελο netprog_basics που θα περιέχει ένα φάκελο .git ο οποίος περιλαμβάνει το πλήρες repository του project με το ιστορικό του. Επίσης θα γίνει check out η τελευταία έκδοση των αρχείων έτσι ώστε να είναι έτοιμα να επεξεργαστούν. Στην περίπτωση αυτή το cloned repository κρατάει τη σύνδεση του με το απομακρυσμένο directory, με το οποίο μπορεί να συγχρονιστεί εκ νέου, εφόσον χρειαστεί να ενημερωθούν τα αρχεία στις τρέχουσες εκδόσεις τους.

Καταγραφή αλλαγών στο Repository

Κάθε αρχείο στο repository Μπορεί να είναι σε μια από τις καταστάσεις tracked ή untracked. Tracked είναι τα αρχεία που αποτέλεσαν μέρος του τελευταίου snapshot και μπορεί να είναι unmodified, modified ή staged. Με λίγα λόγια τα αρχεία σε κατάσταση tracked είναι τα αρχεία που παρακολουθεί το Git. Untracked είναι όλα τα υπόλοιπα αρχεία στον φάκελο που δεν παρακολουθούνται.

Git status

Η κύρια εντολή που χρησιμοποιείται για την παρακολούθηση της κατάστασης των αρχείων είναι git status :

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

Αυτό σημαίνει ότι το working directory είναι clean δηλαδή δεν υπάρχει αλλαγή σε κάποιο από τα αρχεία που είναι σε κατάσταση tracked. Τώρα έστω ότι προσθέτουμε ένα απλό αρχείο README στο working directory και εκτελούμε ξανά την εντολή git status :

$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    README

nothing added to commit but untracked files present (use "git add" to track)

Git Add

Βλέπουμε ότι το αρχείο που προστέθηκε είναι στην κατάσταση untracked οπότε το Git δεν παρακολουθεί τις αλλαγές του. Ουσιαστικά πρόκειται για ένα αρχείο που δεν ήταν μέρος του τελευταίου snapshot (commit). Αν θέλουμε τώρα να αλλάξουμε την κατάσταση του αρχείου σε tracked έτσι ώστε να παρακολουθείται από το Git θα πρέπει να εκτελέσουμε την εντολή git add :

$ git add README
If you run your status command again, you can see that your README file is now tracked and staged to be committed:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

    new file:   README

Πλέον θεωρούμε ότι το αρχείο είναι staged καθώς είναι κάτω από το “Changes to be committed”. Έστω ότι τροποποιούμε τώρα ένα ήδη υπάρχον tracked αρχείο CONTRIBUTING.md και εκτελούμε πάλι την εντολή git status :

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

To αρχείο CONTRIBUTING.md είναι κάτω από το “Changes not staged for commit” που σημαίνει ότι έχουν γίνει αλλαγές στο αρχείο αλλά δεν είναι staged. Για να γίνει staged θα πρέπει να γίνει και αυτό git add :

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Τώρα και τα δύο αρχείο είναι staged και θα αποτελέσουν μέρος του snapshot που θα δημιουργηθεί στο επόμενο commit. Έστω ότι σε αυτό το σημείο γίνεται μια ακόμα τροποποίηση στο αρχείο CONTRIBUTING.md πριν εκτελεστεί το commit :

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Παρατηρούμε ότι το αρχείο CONTRIBUTING.md είναι ταυτόχρονα και staged και unstaged. Αυτό γίνεται γιατί το Git κάνει stage ένα αρχείο στην κατάσταση ακριβώς που βρισκόταν όταν εκτελέστηκε το git add. Οπότε αφού έγιναν και πάλι αλλαγές στο αρχείο για να γίνει staged στην νέα του μορφή θα πρέπει να εκτελεστεί και πάλι η εντολή git add έτσι ώστε στο επόμενο commit να αποθηκευτεί η πιο updated έκδοση του αρχείου :

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Ομαδική προσθήκη αρχείων στο working directory

Είδαμε πως προσθέτουμε ένα - ένα αρχείο στο working directory, ώστε στη συνέχεια να γίνει staged και στη συνέχεια να δημιουργηθεί ένα snapshot με το git commit.

Αν όμως δουλεύουμε με περισσότερα αρχεία και θέλουμε να τα προσθέσουμε όλα στο working directory; Τότε μπορούμε να χρησιμοποιήσουμε την εντολή git add με διαφορετικά ορίσματα, πχ.

• git add . (προσθέτει όλα τα αρχεία στο τρέχον directory, αν κάποια έχουν ήδη προστεθεί, προστίθενται αυτά που λείπουν)
• git add * (το ίδιο με το προηγούμενο)
• git add *.py (μόνο τα αρχεία που έχουν extension ‘.py’)

Git Configuration

Γενικά

Μέχρι τώρα έχουμε δει εντολές που δεν χρειάζονται ιδιαίτερες ρυθμίσεις στο τοπικό μας repository. Ωστόσο προτού προχωρήσουμε στην οριστική υποβολή των αρχείων του repository για τη δημιουργία ενός snapshot ή commit όπως λέγεται, πρέπει να περάσουμε κάποιες βασικές ρυθμίσεις στο repository μας.

Git Config Scopes

Οι ρυθμίσεις για το git ορίζονται σε τρία βασικά επίπεδα:

• Global: Ορίζονται σε επίπεδο χρήστη για όλα τα πιθανά repositories που θα ορίσει ο χρήστης. Συνήθως σε linux systems βρίσκονται σε hidden dir .git κάτω από το home directory του χρήστη.
• System: Ορίζονται σε επίπεδο συστήματος και σε linux συστήματα βρίκονται συνήθως στο /etc/ directory. Δεν είναι σύνηθες να ορίζονται ρυθμίσεις σε αυτό το επίπεδο, η ανάπτυξη μέσω git έχει μεγάλη σχέση με την ταυτότητα του εκάστοτε χρήστη.
• Local: Ορίζονται ανά project directory. Συνήθως βρίσκονται σε hidden dir .git στο directory του project.

Basic configuration

To Git διατηρεί τα αρχεία του σε hidden directory εντός του project όπου αποθηκεύονται δεδομένα και ρυθμίσεις με όνομα .git . Ωστόσο διατηρεί και global ρυθμίσεις σε κεντρικό directory. Το λιγότερο που μπορεί/πρέπει κανείς να ρυθμίσει στο .git/config αρχείο είναι με τις παρακάτω εντολές:

git config user.name "John Doe"
git config user.email johndoe@example.com

Οι ρυθμίσεις μπορούν να γίνουν είτε σε τοπικό επίπεδο ανά project directory είτε σε καθολικό (global) επίπεδο:

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Προβολή Config

Με τις εντολές git config μαζί με τον ορισμό του scope μπορούμε να ρυθμίσουμε, να ακυρώσουμε ρυθμίσεις και να δούμε τις τρέχουσες ρυθμίσεις. Η προβολή των τρεχουσών ρυθμίσεων για το τοπικό project dir γίνεται με την εντολή:

git config --local --list

ή

git config --list

(το local είναι το default). Αντικαθιστώντας την λέξη local με system ή global βλέπουμε τις αντίστοιχες ρυθμίσεις σε επίπεδο system ή global. Παρακάτω βλέπουμε ένα τυπικό output αν δεν έχουμε κάνει τίποτε άλλο πέραν του init:

core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true

Μπορούμε αντίστοιχα να δούμε το αρχείο ρυθμίσεων:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true

Προαπαιτούμενες ρυθμίσεις

To git θα αρνηθεί να προχωρήσει σε commit αν δεν έχουμε ορίσει τις εξής βασικές παραμέτρους που αναφέραμε νωρίτερα:

• user.name
• user.email

Εκτός της χρήσης των εντολών:

git config user.name <user name>
git config user.email <user email>

Διαφορετικά μπορεί κανείς να κάνει κατευθείαν edit το αρχείο:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[user]
        email = user1@example.com
        name = user1name

Με αντίστοιχο τρόπο ορίζονται και άλλες παράμετροι οι οποίες παίζουν ρόλο είτε για λειτουργία σε τοπικό επίπεδο είτε για λειτουργία με απομακρυσμένα repositories. Ενδεχομένως να χρειαστεί να οριστεί και η παράμετρος http.sslVerify σε False.

Τώρα είμαστε έτοιμοι να προχωρήσουμε σε commit!

Git commit

Αφού έχει ολοκληρωθεί η δημιουργία του staging area (και έχουμε ολοκληρώσει τις βασικές ρυθμίσεις) το επόμενο βήμα είναι να γίνουν commit οι αλλαγές. Οποιοδήποτε αρχείο έχει τροποποιηθεί ή έχει δημιουργηθεί και δεν έχει προστεθεί με git add δεν θα αποτελέσει μέρος του επόμενου commit.

git commit

Συνήθως κατά το git commit μας ζητείται να ορίσουμε ένα σύντομο μήνυμα που συνοδεύει το συγκεκριμένο commit. Για να οριστεί κατευθείαν το μήνυμα παράλληλα με το commit, μπορούμε να χρησιμοποιήσουμε την ίδια εντολή με μια μικρή παραλλαγή:

git commit -am "Commit Message"

Παρακάτω φαίνεται ο κύκλος ζωής της κατάστασης των αρχείων στο Git:

Git Log

Βασικό πλεονέκτημα όπως είπαμε των Source Control systems είναι η δυνατότητα να διαχωρίσουμε την πορεία ενός coding project σε διαφορετικά snapshots στο χρόνο και να μπορούμε, αν χρειαστεί, να μετακινηθούμε προς τα πίσω σε συγκεκριμένα σημεία στο “παρελθόν”. Η παρακολούθηση της πορείας των διαδοχικών commits αλλά γενικά και των συμβάντων κατά τη χρήση του git, προκύπτει με τη χρήση της εντολής git log:

git log

ή 
git log --oneline (πολύ διαδεδομένο για να δείχνει κάθε commit σε μόνο μια γραμμή ώστε να φαίνεται συνοπτικά όλο το commit history)

Ειδικά η δεύτερη σύνθεση της εντολής δίνει μια λίστα όπου σε κάθε γραμμή φαίνεται αριστερά ένα hash value για το συγκεκριμένο commit, και το μήνυμα με το οποίο έχει αποθηκευτεί το commit (αυτό που ορίσαμε με το option -am). To hash value είναι ιδιαίτερα σημαντικό για ενέργειες που αφορούν την επιστροφή σε προηγούμενα σημεία του git history.

Π.χ. αν τρέξουμε το command στο repository όπου γράφουμε το παρόν, παίρνουμε το παρακάτω:

1771f5a (HEAD -> master) more changes
b123574 changing..
2ff0bc8 first blocks to introduction to Git
b941b52 Test commit
d4e87c3 updated intro to docker
f844640 added intro to docker

Βλέπουμε ότι υπάρχει κι άλλη πληροφορία εδώ.. π.χ. τί είναι το HEAD -> master) ; Μην βιάζεστε, περισσότερα γι αυτό παρακάτω.

Παραπομπές για git log:

• https://www.thegeekstuff.com/2014/04/git-log/
• https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History
• https://git-scm.com/docs/git-log (documentation για το git log)

Git Head

To Head είναι ο pointer που δείχνει που βρισκόμαστε στο git history αυτή τη στιγμή. H “χειραγώγηση” του HEAD ώστε να δείχνει στο σημείο που θέλουμε είναι πολύ βασικό εργαλείο τόσο για την μετακίνηση στο Git History όσο και μεταξύ Git Branches. Περισσότερα στις περιγραφές των :

• Git Checkout
• Git Reset
• Get Revert

Αναίρεση αλλαγών

Αναίρεση unstaged αλλαγών.

Aς πούμε ότι κάνετε μια αλλαγή και θέλετε να την αναιρέσετε. Αν είχατε προηγουμένως κάνει commit και τρέξετε το git status, θα πάρετε μια απάντηση για το ότι υπάρχουν modified αρχεία, π.χ.

$git status
On branch master
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   content/posts/introduction_to_git.md

no changes added to commit (use "git add" and/or "git commit -a")

Σας αναφέρει ξεκάθαρα “Changes not staged for commit”. Αν θέλετε να γυρίσετε στην προηγούμενη έκδοση ή θα πρέπει να ακολουθήσετε τις οδηγίες για το git restore, ή μπορείτε να τρέξετε την εντολή git checkout με όρισμα το αρχείο που είναι modified, π.χ.

$git checkout content/posts/introduction_to_git.md
Updated 1 path from the index

Το αποτέλεσμα είναι να αναιρεθούν οι αλλαγές και το αρχείο αυτό να επιστρέψει στη μορφή που είχε στο τελευταίο commit. Αν τρέξετε και πάλι git status, θα δείτε ότι το τοπικό working tree είναι καθαρό.

$ git status
On branch master
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

(Προφανώς όταν το έκανα αυτό έχασα τις αλλαγές και ευτυχώς τις είχα αποθηκεύσει αλλού ώστε να τις αποκαταστήσω, γιατί όσο αφορά το git, είχαν αναιρεθεί!) Το git checkout έχει και άλλες χρήσεις, αλλά προς το παρόν ας μείνουμε εντός θέματος στην αναίρεση αλλαγών.

Αναίρεση staging

Έστω ότι προχωρήσατε παρακάτω. Κάνατε stage τς αλλαγές με git add αλλά το μετανιώσατε. Θέλετε να γυρίσετε προς τα πίσω, δηλαδή να κρατήσετε προς το παρόν τις αλλαγές, αλλά να μην είναι πλέον staged. Ή θα χρησιμοποιήσετε την εντολή που σας προτείνει το git, την git restore –staged με όρισμα το αρχείο που έγινε stage, ή θα χρησιμοποιήσετε την εντολή git reset. Π.χ.

$ git status
On branch master
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   content/posts/introduction_to_git.md

$ git reset content/posts/introduction_to_git.md
Unstaged changes after reset:
M       content/posts/introduction_to_git.md
$ git status
On branch master
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   content/posts/introduction_to_git.md

no changes added to commit (use "git add" and/or "git commit -a")

Το αρχείο δεν είναι πλέον staged αρά παραμένει modified.

Αναίρεση commit

Όταν έχει γίνει το commit μπορούμε να γυρίσουμε πίοω ή κατά ένα commit ή για περισσότερα. Οι αλλαγές αναιρούνται σειριακά. Αν γυρίσουμε πίσω τρία commits, τότε ότι έχει γίνει ενδιάμεσα δεν θα υπάρχει πια. Υπάρχουν δύο τρόποι να το πετύχουμε αυτό. Είτε ορίζοντας τον αριθμό των commits που θέλουμε να πάμε πίσω είτε ορίζοντας το hash του commit που θέλουμε να πάμε. Δηλαδή:

$ git log --all --decorate --oneline
530cfac (HEAD -> master) writing git reset
03b1d5e (origin/master, origin/HEAD) working on git reset
cb6ede2 Working on git reset
a2e1f4b working on commit
6a66aa2 working on git reset
5448ed2 ready to share with the team
1e62faa git log, head, remote repo
1771f5a more changes
b123574 changing..
7d77268 Merge branch 'master' of https://github.com/netautogr/hugo adding content for 'Introduction to Git'
2ff0bc8 first blocks to introduction to Git

Προτού προχωρήσουμε είναι σημαντικό να καταλάβουμε τα τρία options που έχουμε για το git reset: soft, mixed και hard. Κάθε μια από τις παρακάτω εντολές μπορούν να χρησιμοποιηθούν και για μεμονωμένα αρχεία.

git reset HEAD~ –soft

Ο HEAD πάει πίσω στο αμέσως προηγούμενο commit και τα τωρινά περιεχόμενα του φακέλου (ότι διαφέρει) εμφανίζονται ως unstaged.

git reset HEAD~ –mixed

Ο HEAD πάει πίσω στο αμέσως προηγούμενο commit και τα τωρινά περιεχόμενα του φακέλου (ότι διαφέρει) εμφανίζονται ως staged. Είναι και η προεπιλογή οπότε η εντολή git reset HEAD~ έχει ακριβώς το ίδιο αποτέλεσμα (χωρίς option)

git reset HEAD~ –hard

Ο HEAD πάει πίσω στο αμέσως προηγούμενο commit και τα τωρινά περιεχόμενα του φακέλου (ότι διαφέρει) διαγράφονται.

git reset HEAD~

Ο HEAD πάει πίσω όσα commit ορίσουμε με το νουμερο. Προφανώς μπορεί να συνδυαστεί με τα options που αναφέραμε νωρίτερα.

git reset HEAD

Γυρνάμε στο HEAD το ίδιο

git reset

Σημαίνει “τράβα το αρχείο από το commit με hash ” (αντί να το τραβήξουμε από το commit που δείχνει ο ΗEAD).

Git Revert

Όπως αναφέραμε όταν κάνουμε git reset --hard, τα περιεχόμενα που είχαμε διαγράφονται οριστικά. Το git reset έχει γενικά και τη συνέπεια ότι το ενδιάμεσο git history που είχε καταγραφεί με τις αλλαγές που θέλουμε να αναιρέσουμε, διαγράφεται επίσης!

Τί γίνεται αν θέλουμε να “επιστρέψουμε στο παρελθόν” στο στυλ που το έκαναν οι εκδικητές στο “Endgame”? Δηλαδή όπως λέει κι ο HULK, όταν επιστρέφεις στο παρελθόν “your past is now your future”! Θέλουμε δηλαδή να φαίνεται η πορεία που είχαμε μέχρις εδώ, ότι αναιρέσαμε μια συγκεκριμένη αλλαγή, και μετά συνεχίσαμε από εκεί. Για το σκοπό αυτό μπορούμε να χρησιμοποιήσουμε την εντολή

git revert 

Η σύνταξη είναι η ίδια. Μας επιτρέπει να κάνουμε ένα “selective undo” για συγκεκριμένο commit διατηρώντας το history μέχρι τώρα. To revert που κάναμε σημειώνεται μπροστά στο git history. Προφανώς ανάλογα με το τί προέκυψε από το revert ενδεχομένως να φτάσουμε στο ίδιο σημείο που περιγράφουμε παρακάτω, με “ασύμβατες αλλαγές”. Ας μην προτρέχουμε όμως. Συνεχίστε να διαβάζετε ;)

Branching & Merging

Η ιδέα πίσω από το branching είναι αυτή της παράλληλης ανάπτυξης νέων features ή παραλλαγών του βασικού κώδικα. Γενικά το git έχει ως σκοπό την οργανωμένη και ασύγχρονη ανάπτυξη κώδικα από πολλαπλές συνεργαζόμενες πλευρές. Όμως δεν είναι ανάγκη να εργάζονται όλοι πάνω σε μία και μοναδική έκδοση του κώδικα που μπορεί να είναι και ο παραγωγικός κώδικας. Μπορούν τα νέα features να αναπτύσσονται σε εκδόσεις του κώδικα οι οποίες “διακλαδίζονται” (branch) από τη βασική και όταν είναι έτοιμα, ο κώδικας τους “συγχωνεύεται” (merge) ξανά με τη βασική.

Άλλη περίπτωση που το branching είναι πολύ χρήσιμο είναι η περίπτωση του κώδικα δοκιμώμ (test branch). Στην περίπτωση αυτή μπορεί στο test branch αυτό να αναπτύσσεται ο κώδικας ο οποίος προκύπτει από τη βασική έκδοση (main/master branch - ναι γιατί έχουμε να λάβουμε υπόψη και την political correctness, τρομάρα μας), ο οποίος τακτικά όταν ολοκληρώνεται ένας κύκλος δοκιμών γίνεται merge πίσω στο βασικό κλάδο.

Branching

Η δημιουργία ενός branch από το βασικό και η αλλαγή πάνω σε αυτό τον κλάδο μπορεί να γίνει με δύο τρόπους:

• Πρώτα δημιουργία του κλάδου και μετά αλλαγή σε αυτών σε δύο βήματα:

git branch <branch-name>
git checkout <brach-name>

• Δημιουργία του κλάδου και αλλαγή σε αυτόν σε ένα βήμα:

git checkout -b <branch-name>

Μπορούμε να γυρίσουμε πίσω στον βασικό κλάδο με

git checkout master

Κάθε φορά που αλλάζουμε κλάδο, τα περιεχόμενα του working directory αλλάζουν για να αντικατατοπτρίσουν την εικόνα του συγκεκριμένου κλάδου.

Merging

Όταν τελειώσουμε την επεξεργασία του διαχωροσμένου κλάδου έρχεται η στιγμή που πρέπει να συγχωνευτεί με τον κύριο κλάδο. Αυτό γίνεται με χρήση της εντολής merge. Για να κάνουμε merge πρέπει να βρισκόμαστε στον κλάδο με τον οποίο θέλουμε να συγχωνευτεί ο διαχωρισμένος. Για να συγχωνεύσουμε τον κλάδο test-feature1 στον master πρέπει πρώτα να επιστρέψουμε στο master και μετά να εκδώσουμε την εντολή merge:

git checkout master
git merge test-feature1

Τα αποτελέσματα της εντολής merge εξαρτώνται από το τί έχει συμβεί στο μεταξύ από όταν είχε δημιουργηθεί ο κλάδος test-feature1 και τι πορεία είχε στο μεταξύ ο κύριος κλάδος. Τρία είναι τα βασικά ενδεχόμενα:

• Δεν έχει γίνει καμία αλλαγή στον κύριο κλάδο. Αυτό που θα συμβεί σε αυτή την περίπτωση είναι γνωστό και ως Fast Forward Merge, δηλαδή ο HEAD απλώς μετακινείται στο τελευταίο commit του test-feature1 κλάδου και αυτά είναι πλέον τα περιεχόμενα του master branch
• Έχουν γίνει αλλαγές και στον κύριο κλάδο αλλά δεν είναι αντικρουόμενες και η συγχώνευση ολοκληρώνεται χωρίς πρόβλημα.
• Έχουν γίνει αλλαγές και στον κύριο κλάδο, οι οποίες δεν είναι συμβατές με τις αλλαγές που έχουν γίνει στον κλαδο test-feature1. Σε αυτή την περίπτωση υπάρχει σύγκρουση (conflict). To git θα μας πληροφορήσει σχετικά και θα μας παρουσιάσει τη σύγκριση των δύο κλάδων. Είτε στο command line είτε σε κάποιο IDE που χρησιμοποιούμε, θα πρέπει χειροκίνητα να επέμβουμε και να διορθώσουμε τη σύγκρουση : 1) αποδεχόμενοι το κομμάτι του κλάδου test-feature1, 2) αποδεχόμενοι το κκομμάτι του κύριου κλάδου, 3) κάνοντας edit το τμήμα της σύγκρουσης όπως νομίζουμε. Με ότι καταλήξουμε, εφόσον κάνουμε εκ νέου commit, αυτό θα μείνει πλέον ως merged περιεχόμενο στον κύριο κλάδο.

Διαγραφή και έλεγχος branches

Στη συνέχεια μπορούμε αν θέλουμε να διαγράψουμε τον κλάδο που είχαμε δημιουργήσει με την εντολή:

git branch -d <branch-name>

Μπορούμε να δούμε όλα τα branches με την εντολή:

git branch --all

Εφόσον λειτουργούμε σε ένα πλαίσιο CI/CD (Continuous Integration/Continuous Deployment/Delivery) ενδεχομένως κάποια branches να αναπτύσσονται συνεώς και ο κώδικας που αναπτύσσεται σε ξεχωριστό περιβάλλον π.χ το test brach πιθανόν να γίνεται deploy μετά από κάθε commit στο test περιβάλλον.

Αν θέλει κανείς να δει το ιστορικό των commit’s διευκολύνοντας μας στην παρακολούθηση των branching and merging, μπορεί να εκτελέσει την παρακάτω εντολή:

git log --all --decorate --oneline --graph

* 6e596fb (HEAD -> master, origin/master, origin/HEAD) finishing merging
* 530cfac writing git reset
* 03b1d5e working on git reset
* cb6ede2 Working on git reset
* a2e1f4b working on commit
* 6a66aa2 working on git reset
* 5448ed2 ready to share with the team
* 1e62faa git log, head, remote repo
* 1771f5a more changes
* b123574 changing..
*   7d77268 Merge branch 'master' of https://github.com/netautogr/hugo adding content for 'Introduction to Git'
|\  
| * b941b52 Test commit
* | 2ff0bc8 first blocks to introduction to Git
|/  

Δουλεύοντας με repote repositories

Γενικά

Από τη στιγμή που κάποιος αναπτύσσει μέσα σε μια ομάδα, έχει πλέον νόημα η χρήση remote online repositories όπου θα γίνεται συγχρονισμός και θα καθορίζεται η συνεργασία με το πλαίσιο που ορίζει το git. Οι προβλεπόμενες δομές και διαδικασίες προχωράνε σε βάθος, ωστόσο για αρχή θα πρέπει κάποιος να ορίσει τις αντίστοιχες ρυθμίσεις για το remote repository και τον τρόπο login/authenticate σε αυτό. Εφόσον η ανάπτυξη γίνεται με κάποιο IDE που είναι git friendly, oι ρυθμίσεις αυτές θα πρέπει να προσαρμοστούν και να συνδυαστούν με αντίστοιχες ρυθμίσεις εντός του IDE, ώστε οι βασικές ενέργειες που εκτελούνται με το Git να μπούν να εκτελεστούν με μεγάλη ευκολία με το GUI του IDE.

Public & Private Repositories/Servers

Η συνεργασία δεν έχει νόημα αν δεν ανεβεί περιεχόμενο σε server που να έχουν πρόσβαση και άλλοι developers. Γνωστά sites που δίνουν τέτοια δυνατότητα είτε για δημόσια repositories ή για repositories περιορισμένης πρόσβασης, είναι το Github - https://github.com και το Gitlab - https://about.gitlab.com/ . Αν θέλετε να στήσετε ιδιωτικό repository στο enterprise περιβάλλον που εργάζεστε, αυτό είναι σαφέστατα πιο εύκολο με το gitlab το οποίο διαθέτει και έκδοση δωρεάν για τέτοιο σκοπό. Το πως μπορεί κανείς να στήσει το gitlab σε τέτοια μορφή είναι πέρα από το scope του παρόντος άρθρου. Το Gitlab διαθέτει και ενισχυμένες δυνατότητες για enterprise level DevOps (CI/CD κλπ) στο ίδιο προϊόν. Από την άλλη, το Github είναι πλέον στον έλεγχο της Microsoft, η οποία είναι πίσω από την ανάπτυξη του Visual Studio Code (πολύ διαδεδομένου IDE για ανάπτυξη κώδικα), το οποίο δίνει αυξημένες δυνατότητες integration μεταξύ του εργαλείου και του Github, χωρίς ιδιαίτερο κόπο.

Ελάχιστες ενέργειες

Δύο είναι τα βασικά σενάρια:

• Δημιουργείτε ένα τοπικό repository το οποίο θέλετε στη συνέχεια να ανεβάσετε σε ένα Git Server ώστε να είναι εφικτή η συνεργασία με τρίτους γι αυτό το project.
• Τραβάτε τον κώδικα από ένα remote repository από κάποιον git server σε τοπικό directory και στη συνέχεια προχωράτε σε τοπική επεξεργασία του project συγχρονίζοντας κατά διαστήματα τις αλλαγές τόσο τις δικές σας προς το remote όσο και άλλες αλλαγές που συμβαίνουν στο remote και γίνονται commit & push από άλλους, στο δικό σας τοπικό repository.

Και στις δύο περιπτώσεις είναι απαραίτητο να έχετε δημιουργήσει χρήστη στην απομακρυσμένη πλατφόρμα και να έχετε την κατάλληλη πρόσβαση/δικαιώματα είτε για να φτιάξετε νέο project είτε για να συμμετέχετε στην ανάπτυξη ενός υπάρχοντος. Αυτές οι ενέργειες γίνονται στην ίδια την πλατφόρμα και προηγούνται. Στη συνέχεια η επικοινωνία γίνεται με δύο δυνατούς τρόπους:

• μέσω ssh (τελεί υπό κατάργηση)
• μέσω https (συνήθως μέσω API Token)

Δημιουργία remote/upstream από local repository

Στo πρώτo σενάριο είναι απαραίτητο να έχετε ορίσει δύο βασικά κομμάτια ρυθμίσεων:

• Την τοποθεσία του remote repository και τον ορισμό του ως upstream
• Την αντιστοίχιση του τοπικού τρέχοντος branch με αντίστοιχο branch στο remote/upstream

Οι απαραίτητες εντολές είναι οι:

• git remote add origin .git - ορίζει ως origin (remote) το remote repo url
• git branch –set-upstream-to origin/ - ορίζει το remote branch ως upstream του τρέχοντος τοπικού branch. Αν το τρέχον είναι το master, τότε η εντολή:

git branch --set-upstream-to origin/master 

καθορίζει το remote master ως αντίστοιχο upstream του local master branch.

Στη συνέχεια μπορούμε να εκτελέσουμε την εντολή

git push origin master 

για να συγχρονίσουμε το remote master branch με τις τελευταίες αλλαγές του τοπικού master.

Οι κινήσεις αυτές μπορούν να γίνουν και σε ένα βήμα με την εντολή:

git -c http.sslVerify=false push --set-upstream <remote repo url>.git <remote branch>

Αν πρέπει πρώτα να τραβήξουμε τυχόν αλλαγές από το remote repo τότε εκτελούμε την εντολή:

git pull 

Δημιουργία local repository από remote/upstream

Αυτό γίνεται με απλό τρόπο με τη χρήση της εντολής git clone:

git clone https://<username>:<API_Token>@<remote repo url>.git <local path - optional> --progress

Έλεγχος ρυθμίσεων

Αν δείτε ότι κατόπιν εκτέλεσης της εντολής υπολείπονται ρυθμίσεις στο config, μπορείτε να εφαρμόσετε τις εντολές που αναφέραμε παραπάνω για να τις συμπληρώσετε (π.χ. git branch –set-upstream-to) Μπορείτε να χρησιμοποιήσετε την εντολή git remote -v και το git status remote για να ελέγχετε την κατάσταση.

Authentication

Ένας απλός τρόπος είναι να ορίσετε στο config ότι τα credentials αποθηκεύονται σε τοπικό αρχείο με την εντολή:

git config credential.helper store --file <filepath>

ή σε επίπεδο χρήστη με την εντολή

git config --global credential.helper store --file <filepath>

Στη συνέχεια στην πρώτη προσπάθεια για git push ή git pull, θα πάρετε prompt για το password του χρήστη με user name αυτό που ορίσατε στο config. Εδώ προφανώς με όσα γράφουμε μέχρι τώρα, το password αντιστοιχεί στο https API Token.

Η επιτυχημένη εργασία με remote repositories είναι η βάση για τη συνεργατική ανάπτυξη κώδικα σε κοινά project ομάδων, ανεξάρτητα με την τοποθεσία των μελών της εκάστοτε ομάδας.

The CLI way or the IDE way?

Αν χρησιμοποιείτε IDE όπως το Visual Studio Code, τo authentication προς γνωστά remote sites γίνεται πιο εύκολα εφόσον το επιθυμούμε. Στην περίπτωση του github μπορεί να γίνει login από το profil του χρήστη ή να δοθεί εξουσιοδότηση από τη σελίδα του Github προς το visual studio code αν εκτελέσει κανείς το κατάλληλο link. Αλλά και οι υπόλοιπες εργασίες, όπως το git init, add, commit, add remote, git push, pull, branch, status, log, κλπ μπορούν να εκτελεστούν με τη βοήθεια VS Code extensions, όπως:

• gitlab workflow
• gitlab explorer
• git lens
• git autoconfig
• git automator
• git history
• git-ignore

κλπ. Κάθε extension έχει δικό της κομμάτι στο αρχείο ρυθμίσεων του vs code. Το αρχείο είναι διαμορφωμένο σε μορφή json.

Σημαντικά links

Γενικά

https://git-scm.com/book/en/v2/ https://ohshitgit.com/ https://developer.cisco.com/learning/tracks/devnet-beginner/programming-fundamentals/git-basic-workflows/step/1 https://towardsdatascience.com/an-easy-beginners-guide-to-git-2d5a99682a4c https://community.codenewbie.org/wolde_ai/git-learn-the-basics-part-one-1f6b https://towardsdatascience.com/the-only-6-git-commands-you-need-to-know-995065db1ae0 https://towardsdatascience.com/learn-enough-git-to-be-useful-281561eef959 https://www.freecodecamp.org/news/understanding-git-basics-commands-tips-tricks/ https://towardsdatascience.com/mastering-git-commands-the-logic-behind-git-ad3fbcc6fb33

Git Branching

https://learngitbranching.js.org/ https://www.freecodecamp.org/news/how-to-use-branches-in-git/

Visual Studio - Git Integration

https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/The-New-Git-Experience https://devblogs.microsoft.com/visualstudio/enhanced-productivity-with-git-in-visual-studio/ https://docs.microsoft.com/en-us/visualstudio/version-control/?view=vs-2019

Git Tutorials - Labs

https://git-scm.com/docs/gittutorial https://youtu.be/DVRQoVRzMIY https://www.youtube.com/watch?v=USjZcfj8yxE https://developer.cisco.com/learning/tracks/devnet-beginner/programming-fundamentals/git-basic-workflows/step/1 https://developer.cisco.com/learning/lab/git-intro/step/1 https://developer.cisco.com/learning/lab/collab-tools-python-scripting-basics-with-git-itp/step/1 https://developer.cisco.com/learning/lab/git-branching/step/1 https://developer.cisco.com/learning/lab/git-servers/step/1 https://css-tricks.com/creating-the-perfect-commit-in-git/ https://levelup.gitconnected.com/top-30-git-commands-you-should-know-to-master-git-cli-f04e041779bc https://www.freecodecamp.org/news/advanced-git-interactive-rebase-cherry-picking-reflog-and-more/ https://github.com/GitCredentialManager/git-credential-manager https://dzone.com/articles/the-best-vs-code-extensions-to-supercharge-git https://dev.to/sagarbarapatre/how-to-become-a-git-expert-1jl2 https://dev.to/mrdanishsaleem/git-cheatsheet-4kpn https://towardsdatascience.com/a-git-cheatsheet-that-all-coders-need-bf8ad4d91576 https://www.freecodecamp.org/news/git-for-professionals/ https://towardsdatascience.com/how-to-learn-git-in-simple-words-263618071dd8 https://www.sitepoint.com/5-ways-to-undo-mistakes-with-git/ https://dev.to/sankalpswami1122/git-essentials-4kff https://levelup.gitconnected.com/using-git-in-visual-studio-code-2f16fde8406e

Next steps

Στην επόμενη version του άρθρου θα προσθέσουμε βασικά στοιχεία για το πως μπορεί κάποιος να διαχειριστεί το git σε ένα project μέσα από ένα IDE όπως το Visual Studio Code καθώς και να καθορίσει remote repositories (upstream/origin) και να χρησιμοποιήσει git servers για το συγχρονισμό των projects για ομάδες και κατά προέκταση σε συνδυασμό με εργαλεία CI.