Ερώτηση σε git

[Dr.Fuzzy]

Τα φώτα σας παιδιά.

 

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

 

Η ερώτηση ειναι η εξής. Ποια ειναι πιο σωστή τακτική, να βάλουμε ενα tag στη version των πρώτων αποτελεσμάτων και να συνεχίσουμε τις προσθήκες στο ιδιο branch βάζοντας ενα νέο tag στην επόμενη έκδοση ή να δημιουργήσουμε ενα νέο branch και εκεί να συνεχίσουμε με τις προσθήκες;

[defacer]

Τα σενάρια που περιγράφεις δεν έχουν καμία ουσιώδη διαφορά αφού μπορείς οποιαδήποτε στιγμή στο μέλλον θελήσεις να περάσεις από το ένα στο άλλο και αντίστροφα.

 

Από άποψη πιο ταιριαστής οργάνωσης εφόσον διατηρεί και τους παλιούς αλγόριθμους το πρώτο σενάριο μου ακούγεται πολύ προτιμότερο.

[Dinos_12345]

Το καλύτερο είναι να βάλεις ένα νέο branch για να κάνεις ότι θες, ακόμα και ένα branch που να κάνεις test δουλειά αυτού του branch. Όσο το σπας, κρατάς το main καθαρό και όταν είναι έτοιμες οι αλλαγές και νομίζεις ότι είναι σταθερό, κάνεις το merge.

[Dr.Fuzzy]

@defacer

Δεν εχεις άδικο, λαβέ μόνο υπόψη σου οτι (my bad ξέχασα να το διευκρινήσω) οτι τα πρώτα αποτελέσματα παρήχθησαν με synthetic data ενώ τα καινούρια (με τους επιπλέον αλγόριθμους) θα υπάρχει επιλογή να χρησιμοποιούν και real-data (μεταφράζεται σε σημαντικές αλλαγές στο interface και την ύπαρξη ενός cluster κλπ που τα παρέχει)

@dinos_12345

Αν απλά φτιάξω ενα νέο branch αλλα χωρίς να εχω σκοπό να το κάνω ποτε merge;

 

Η αρχική ερώτηση παιδιά προκύπτει απο το εξής που ίσως και να ειναι λάθος σαν προβληματισμός. Έστω κάποιος παίρνει το πρώτο κείμενο και θέλει τον κώδικα για να κανει reproduce. Στην περίπτωση του 1ου σεναρίου, δεν ειναι λιγο ανορθόδοξο να του πω κάνε git clone αλλα την τάδε version και όχι την current (φυσικα και με την τρέχουσα θα μπορει απλά θα εχει έξτρα πράγματα μέσα που δε χρειάζεται); Γιαυτο το λόγο σκέφτηκα το branching. Αν το σκέφτομαι λάθος, shoot!

[Dinos_12345]

Αν δεν έχεις σκοπό να κρατήσεις μία από τις δύο, τότε καλύτερα να κάνεις ένα άλλο repo. Τα branches δεν είναι τόσο για να διαχωρίσεις εκδόσεις σε κάτι, αλλά πιο πολύ σαν εργαλεία για να κάνεις push κάτι χωρίς να πειράζεις το ήδη υπάρχον και λειτουργικό version.

[pmav99]

Είναι απαραίτητο να γίνουν commit τα αποτελέσματα;

 

Αν όχι, τότε απλά προσθέτεις tags και δεν κάνεις τίποτα άλλο. Απλά γράφεις στο readme/wherever ότι τα τάδε αποτελέσματα προκύπτουν αν κάνεις checkout το commit αυτό και τρέξεις τον κώδικα με το δείνα input.

 

Αν πάλι πρέπει/χρειάζεται να σώσεις το output, προσωπικά θα πρότεινα κάτι σαν το εξής:

 

1. Προσθέτεις tags (πχ v1, v2, v3 κτλ)

2. Δημιουργείς ένα φάκελο output ο οποίος έχει υποφακέλους με το όνομα του κάθε tag. O Κάθε υποφάκελος τώρα περιέχει μέσα τα δεδομένα που χρειάζονται για να παραχθούν τα αποτελέσματα + τα αποτελέσματα των υπολογισμών. Αν το format του input δεν αλλάζει μεταξύ των διάφορων versions δεν είναι ανάγκη να επαναλαμβάνεις το input σε κάθε φάκελο (αν και μπορεί να κάνει το replication ευκολότερο).

 

Με τον τρόπο αυτό κάνοντας checkout το commit που θες μπορείς εύκολα να αναπαράγεις και να συγκρίνεις το output.

 

ΥΓ Ένα παράδειγμα χρήσης αυτού του μοντέλου μπορείς να δεις στο Mesosphere Universe. Πχ υπάρχουν 18 εκδόσεις για το Jenkins. Αντίστοιχα για τα άλλα πακέτα

 

https://github.com/mesosphere/universe

https://dcos.io/blog/2016/a-developer-s-guide-to-the-universe/index.html

 

ΥΓ2. Εννοείται ότι μπορείς να μεταφέρεις ολόκληρο τον φάκελο output σε ξεχωριστό repo. Ιδιαίτερα μάλιστα αν το μέγεθος του input/output είναι μεγάλο.

[Dr.Fuzzy]

Τα input data όχι δε φυλάσσονται κάπου, παράγονται από μια γεννήτρια διανυσμάτων (αν είναι synthetic) ή λαμβάνονται από ένα cluster setup (αν είναι real) σε runtime. Τo i/o dataset σώζεται σε ένα .dat προκειμένου να μπορούν να γίνουν reproduce τα sim graphs χωρίς να χρειαστεί να ξανατρέξει το sim αλλά δεν γίνεται commit στο repo, δε χρειάζεται.

 

Νομίζω ότι τα version tags είναι το πιο λογικό όπως το βλέπω δεδομένου ότι το realdata_version είναι extension στο synthetic_version, οπότε πχ, doc1 και clone την synthetic_version (ή την current δηλαδή synthetic_version αλλά με επιπλέον options που δεν θα κάνουν apply στο doc1), doc2 και clone την current. Το branching με τον τρόπο που το σκέφτηκα είναι όντως ανορθόδοξο. Ίσως ένα branch με το realdata_version (για να μείνει καθαρό το master από διαδοχικά commits) και στο τέλος merge στο master branch και tag.

[ParhsG]

Τα tags απλα δείχνουν σε ενα συγκεκριμένο commit και αν κανεις clone απο εκει δε μπορείς να το τροποιποιήσεις(commit κτλ). Νομιζω οτι αν θες να εχεις δυο "εκδοσεις" ταυτοχρονα πχ κανεις ενα branch απο το τωρινό σου και το λες synthetic-data  και συνεχίζεις κανονικά με το άλλο. Επισης χώνεις και ενα tag synthetic-data-v1.0 πχ ωστε να ξέρεις που ηταν η εκδοση που δούλευε. Ετσι αν προκύψει κάποιο bug η θέλει καποιος να το συνεχίσει να μπορεί να κανει κανονικα commit σε αυτο το branch και θα ξέρεις και που ησουν οταν το πρωτοεκανες. Θα παρεκλινουν αλλά δε σε νοιάζει απο οτι καταλαβαίνω  που ειναι λογικό.

Ειναι σαν να εχεις εκδοσεις πχ 1.1.x 1.3.x και να εχεις αλλο branch για τη καθε μια ετσι ωστε να δινεις update για καθε version χωριστα.

Δε ξερω αν καταλαβα το προβλημα σου σωστά αλλα αυτο νομιζω πως θες 

[defacer]

Fuzzy και Πάρης, λέτε και οι δύο "clone συγκεκριμένο πράγμα" (όχι με τα ίδια λόγια). Τι φάση; Clone κάνεις όλο το repo, και μετά checkout ο,τι αγαπάς όσο αγαπάς.

 

 

Η αρχική ερώτηση παιδιά προκύπτει απο το εξής που ίσως και να ειναι λάθος σαν προβληματισμός. Έστω κάποιος παίρνει το πρώτο κείμενο και θέλει τον κώδικα για να κανει reproduce. Στην περίπτωση του 1ου σεναρίου, δεν ειναι λιγο ανορθόδοξο να του πω κάνε git clone αλλα την τάδε version και όχι την current (φυσικα και με την τρέχουσα θα μπορει απλά θα εχει έξτρα πράγματα μέσα που δε χρειάζεται); Γιαυτο το λόγο σκέφτηκα το branching. Αν το σκέφτομαι λάθος, shoot!

 

Δε βλέπω κανένα πρόβλημα σ' αυτό. Αν έχουν τόσο μεγάλη διαφορά μεταξύ τους θα μπορούσαν να είναι και ξεχωριστά repo, αλλά δε νομίζω πως είναι τέτοια φάση.

 

Πιο πολύ απ' ότι μυρίζομαι υπάρχουν αρκετές "σωστές λύσεις" στην περίπτωσή σου, οπότε πρακτικά κάνε ό,τι σου φαίνεται ΟΚ σήμερα και αύριο μπορείς να επανεξετάσεις.

 

Τα tags απλα δείχνουν σε ενα συγκεκριμένο commit και αν κανεις clone απο εκει δε μπορείς να το τροποιποιήσεις(commit κτλ). 

 

Φυσικά και μπορείς να κάνεις checkout οποιοδήποτε commit θέλεις και να συνεχίσεις από εκεί και να κάνεις branch μετά ή οτιδήποτε άλλο. Μήπως δεν είναι ξεκάθαρο το πώς δουλεύουν όλα αυτά στο git?

• Τα πάντα είναι commits.
• Τα tags είναι αυθαίρετα επιλεγμένα ονόματα τα οποία για δική μας ευκολία μπορούμε να δώσουμε σε κάποιο commit. Αν δεν υπήρχαν απλώς θα έπρεπε να χρησιμοποιούμε πιο "άβολα" ονόματα".
• Τα branches είναι tags τα οποία για δική μας ευκολία μετακινούνται μόνα τους από ένα commit σε άλλο. Αν δεν υπήρχαν απλώς θα έπρεπε να μετακινούμε τα tags μόνοι μας.

Όσον αφορά το ίδιο το git, tags και branches θα μπορούσαν να μην υπάρχουν καν και λειτουργικά δε θα άλλαζε απολύτως τίποτα. Ο λόγος που υπάρχουν είναι για να διευκολύνουν εμάς. Οπότε, δεν υπάρχει ποτέ περίπτωση να συναντήσουμε λειτουργική διαφορά σε ο,τι κάνουμε επειδή δουλέψαμε με tag ή με branch ή με οτιδήποτε. Απλά κάποια πράγματα είναι πολύ πιο εύκολα και γρήγορα να γίνουν όταν χρησιμοποιούμε tag/branch.

[Dr.Fuzzy]

Λοιπόν όπως το βλέπω θα κάνω το εξής:

 

tag synthetic_v1.0 στην έκδοση με την οποία παράχθηκαν τα αποτελέσματα στο doc1, από εκεί create branch realdata και μετά από no. of commits merge με το main branch και tag synthetic_real_v1.0 για το doc2.

 

Τώρα, αν κάποιος θέλει να κάνει reproduce τα results στο doc1 ή doc2 κάνει clone την current αφού έτσι και αλλιώς "θα κουβαλάει" και τα options της synthetic_v1.0, απλά ίσως να διευκρινίζεται στο README ότι η current έχει extra options (realdata) που δεν κάνουν apply στο doc1 (βεβαίως αν θέλει κάνει clone και checkout την specific version).

 

Sounds right?