Παιχνίδι 2048 σε C

[imitheos]

Πω πω παιδιά, χάθηκα τελείως! Πρέπει να ρίξω πολύ διάβασμα

Μάλλον γιατί, όπως πάντα, το εξήγησα χάλια

 

Τι δεν κατάλαβες να (προσπαθήσω να) το περιγράψω πιο λεπτομερώς.

[migf1]

Δεν νομίζω να εξήγησες εσύ κάτι χάλια. Εγώ δεν έχω ικανή εξοικείωση για να παρακολουθήσω αυτά που εξήγησες!

 

Να το κρατήσουμε προς το παρόν όσο πιο απλό γίνεται; Θα μπορούσες κάποια στιγμή να ποστάρεις το πιο απλό workflow που μπορείς να σκεφτείς (ή όποιος άλλος φυσικά) και που θεωρείς ότι θα μας βολέψει για το συγκεκριμένο πρότζεκτ;

[geomagas]

Πω πω παιδιά, χάθηκα τελείως! Πρέπει να ρίξω πολύ διάβασμα

 

Εμ, τι ήθελες κι εσύ τα version bumps;;;

 

Πλάκα κάνω, εννοείται!

 

 

@imitheos: Έκανα

git remote -v set-url --push origin https://github.com/geomagas/2048cc.git

...αλλά μετά στο push συμπεριφέρεται σαν το clone με http. Κάτι παίζει με το http, και δεν θέλω να το ψάξω.

 

Οπότε το γύρισα πίσω σε git://. Τι πρέπει να κάνω για να χρησιμοποιώ μόνο τα git:// (over ssh φαντάζομαι);

Να το κρατήσουμε προς το παρόν όσο πιο απλό γίνεται; Θα μπορούσες κάποια στιγμή να ποστάρεις το πιο απλό workflow που μπορείς να σκεφτείς (ή όποιος άλλος φυσικά) και που θεωρείς ότι θα μας βολέψει για το συγκεκριμένο πρότζεκτ;

 

Βρε δεν είναι θέμα workflow... Για κάτι τέτοιο, το workflow μου φαίνεται κατανοητό (για άλλα πράγματα, δεν παίρνω κι όρκο...).

[imitheos]

Δεν νομίζω να εξήγησες εσύ κάτι χάλια. Εγώ δεν έχω ικανή εξοικείωση για να παρακολουθήσω αυτά που εξήγησες!

 

Να το κρατήσουμε προς το παρόν όσο πιο απλό γίνεται; Θα μπορούσες κάποια στιγμή να ποστάρεις το πιο απλό workflow που μπορείς να σκεφτείς (ή όποιος άλλος φυσικά) και που θεωρείς ότι θα μας βολέψει για το συγκεκριμένο πρότζεκτ;

Το git-flow είναι πολύ καλό workflow που καλύπτει τα πάντα. Το κακό είναι ότι καλύπτει τα πάντα και είναι overkill για τα περισσότερα projects. Οπότε για το παρόν project, μπορούμε να αφαιρέσουμε το develop branch και να γίνεται ανάπτυξη στο master.

 

Επίσης μπορούμε να αφαιρέσουμε τα release branches. Ένα μεγάλο project (όπως πχ το FreeBSD) έχει να υποστηρίξει πολλαπλές εκδόσεις. Aυτή τη στιγμή το FreeBSD αναπτύσσει τις 10, 9, 8 εκδόσεις οπότε ένα critical fix που περνάει στο HEAD θα πρέπει να περαστεί και στην 9 και στην 8. Εσείς δεν έχετε τέτοιο θέμα οπότε φεύγουν και τα release branches.

 

Αυτό που μένει εξηγείται με καλύτερα λόγια από τα δικά μου και με ωραία σχηματάκια εδώ από το ίδιο το github. Το κύριο branch είναι το master το οποίο πρέπει κάθε στιγμή να γίνεται compile σε όλες τις πλατφόρμες που σε ενδιαφέρουν και να μην έχει bugs (όσο αυτό είναι δυνατόν φυσικά).

 

Από εκεί και πέρα για κάθε αλλαγή δημιουργείς ένα branch με βάση master με περιγραφικό όνομα και δουλεύεις εκεί. Το κάνεις και push στο github ώστε να το βλέπει και ο geomagas. Όταν τελειώσεις τη δουλειά και στείλεις request συζητάτε αν είναι καλό και τι αλλαγές χρειάζεται. Αφού αποφασίσετε στην τελική μορφή, βεβαιώνεσαι ότι κάνει compile και παίζει σωστά και το κάνεις merge. Το testing σε αυτό το σημείο είναι απαραίτητο γιατί μπορεί δύο features που έπαιζαν τζάμι από μόνα τους να δημιουργούν κάποιο πρόβλημα όταν ενσωματωθούν και τα δύο

 

Αυτά τα 5 βήματα που περιγράφονται στο παραπάνω url είναι το πιο απλό που μπορείς να κάνεις.

@imitheos: Έκανα

git remote -v set-url --push origin https://github.com/geomagas/2048cc.git

...αλλά μετά στο push συμπεριφέρεται σαν το clone με http. Κάτι παίζει με το http, και δεν θέλω να το ψάξω.

 

Οπότε το γύρισα πίσω σε git://. Τι πρέπει να κάνω για να χρησιμοποιώ μόνο τα git:// (over ssh φαντάζομαι);

 

% git clone git://github.com/geomagas/2048cc.git 
Cloning into '2048cc'...
remote: Counting objects: 221, done.
remote: Compressing objects: 100% (111/111), done.
remote: Total 221 (delta 132), reused 178 (delta 108)
Receiving objects: 100% (221/221), 972.54 KiB | 276.00 KiB/s, done.
Resolving deltas: 100% (132/132), done.
Checking connectivity... done

% cd 2048cc 
% git push
fatal: remote error: 
  You can't push to git://github.com/geomagas/2048cc.git
  Use https://github.com/geomagas/2048cc.git

% git remote set-url --push origin https://github.com/geomagas/2048cc.git                                          
% git push
Username for 'https://github.com': geomagas     
Password for 'https://[email protected]': 
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/geomagas/2048cc.git/'   <-- λογικό μια και έβαλα 123 για pass

% git remote set-url --push origin https://[email protected]/geomagas/2048cc.git
% git push
Password for 'https://[email protected]':      <---- τώρα ζητάει μόνο pass και όχι username
remote: Invalid username or password.
fatal: Authentication failed for 'https://[email protected]/geomagas/2048cc.git/'

[geomagas]

...
% git remote set-url --push origin https://github.com/geomagas/2048cc.git                                          
% git push
Username for 'https://github.com': geomagas     
Password for 'https://[email protected]': 
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/geomagas/2048cc.git/'   <-- λογικό μια και έβαλα 123 για pass

...

Ναι αυτό έκανα. Για κάποιο λόγο (που όπως είπα δεν θέλω να ψάξω περαιτέρω) δεν προχωρά στο Username, αλλά "κολλάει".

Γενικά, έχει την ίδια συμπεριφορά με https, είτε κάνω clone είτε push είτε οτιδήποτε.

 

UPDATE: Τελικά τα κατάφερα από άλλο μηχάνημα, όπου δούλεψε με https. @migf1, αν θέλεις κάνε ένα cross check μην έχω κάνει καμια πατάτα...

[migf1]

@geomagas:

 

Δεν εννοούσα workflow ειδικά για τα tags, αλλά ένα απλό γενικότερο workflow για να το υιοθετήσουμε.

 

@imitheos:

 

Μόλις διάβασα το link με τα σχηματάκια (ωραίο). Νομίζω μοιάζει αρκετά με αυτό που κάνουμε μέχρι τώρα, έτσι δεν είναι; Η 1η απορία που έχω πάντως είναι πως θα δημιουργήσω εγώ ένα δικό μου branch στο blessed/master ώστε να το βλέπουν κι οι υπόλοιποι;

 

Μήπως εννοεί πως όταν κάνω pull-request για το branch μου στον geomagas, εκείνος αντί να το κάνει merge στο blessed/master να το περάσει (με κάποιον τρόπο) ως branch με το ίδιο όνομα που του έχω δώσει εγώ, στο blessed repo?

 

Μια 2η απορία είναι πως συγχρονίζονται στο git/github 2 ή περισσότεροι contributors αν τα διαφορετικά τους branches πειράζουν/αλλάζουν κοινά πράγματα στη κοινή αφετηρία τους, που είναι το blessed/master (αν δηλαδή κάνει merge ο geomagas τα branches των 2 contributors στο blessed/master, ποιανού contributor οι αλλαγές θα υπερισχύσουν... το πάει χρονικά; )

 

Μια 3η μου απορία είναι πως δεν έχω καταλάβει πως γίνεται γενικά ο συγχρονισμός στο git/github όταν δουλεύουν πολλοί ταυτόχρονα σε πράγματα που είναι κοινά.

 

...

UPDATE: Τελικά τα κατάφερα από άλλο μηχάνημα, όπου δούλεψε με https. @migf1, αν θέλεις κάνε ένα cross check μην έχω κάνει καμια πατάτα...

Σωστό δείχνει

[pmav99]

το πιο απλό είναι να έχετε ένα μονο repo ώστε να μην μπλέκεται ούτε με Pull requests ούτε με τίποτα. Δύο βασικοί devs είστε και λογικό είναι να δουλεύετε με ένα κεντρικό repo. Απλά δουλεύετε σε branches το κάθε feature (o καθένας μόνος του ή και οι δύο μαζί) και τέλος. Όταν κάνει contribute κάτι κάποιος 3ος μέχρι να σας πείσει ότι του αξίζει να γίνει core dev, τον αφήνετε να κάνει αυτός pull requests κτλ.

 

Άυτά που θέλουν προσοχή όταν έχεις ένα κοινό repository είναι

 

α) Να αποφασίσετε ποιος/πότε θα κάνει merge στο master.

 

β) Ό,τι αλλαγές κάνετε (εκτός και αν είναι τελείως trivial, πχ ορθογραφικά λάθη) να τα κάνετε σε feature branches.

 

γ) να κάνετε git fetch αντί για git pull. Έτσι θα τραβάτε ότι αλλαγές έχει κάνει ο άλλος και θα μπορείτε να τις ελέγξετε με gitk, git log ή κάποιο GUI. Αφού τις δείτε και πειστείτε ότι είναι οκ κάνετε git merge και κάνετε resolve τα conflicts αν υπάρχουν. Αν δεν είναι ΟΚ απλά επικοινωνείτε μεταξύ σας για να δείτε τι θα κάνετε (πχ στέλνετε email / ποστάρετε στο forum / κάνετε comment στο commit μέσω του github / τα συζητάτε στο bug tracker / whatever)

 

To git pull == git fetch + git merge και μπορεί να κανει τη ζωή σας δύσκολη.

 

Προαιρετικά, πριν κάνετε merge στο master, μπορείτε να κάνετε και κανένα rebase στο feature branch για να έχετε πιο καθαρό history (λιγότερα trivial commits)

[imitheos]

@imitheos:

 

Μόλις διάβασα το link με τα σχηματάκια (ωραίο). Νομίζω μοιάζει αρκετά με αυτό που κάνουμε μέχρι τώρα, έτσι δεν είναι; Η 1η απορία που έχω πάντως είναι πως θα δημιουργήσω εγώ ένα δικό μου branch στο blessed/master ώστε να το βλέπουν κι οι υπόλοιποι;

Μέχρι τώρα πως το έκανες ? Πως έκανες τα REPLAY_NEXTMV, SaveLongReplays, ImproveComments ?

 

Όταν ένα branch που δημιούργησες τοπικά από το tortoise το κάνεις push αυτό φαίνεται στο github.

 

Άλλος τρόπος είναι να το δημιουργήσεις μέσω του UI του github (όταν κάνεις κλικ στο branch σου έχει ένα search box στο οποίο όταν γράψεις κάτι που δεν υπάρχει το κουμπί αλλάζει σε "create") και μετά να το κάνεις fetch αλλά αυτό θα σε μπερδέψει πιο πολύ. Κάνε το όπως το έκανες μέχρι τώρα με push.

 

Μια 2η απορία είναι πως συγχρονίζονται στο git/github 2 ή περισσότεροι contributors αν τα διαφορετικά τους branches πειράζουν/αλλάζουν κοινά πράγματα στη κοινή αφετηρία τους, που είναι το blessed/master (αν δηλαδή κάνει merge ο geomagas τα branches των 2 contributors στο blessed/master, ποιανού contributor οι αλλαγές θα υπερισχύσουν... το πάει χρονικά; )

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

 

Όσο δουλεύουν στα διαφορετικά branches δεν υπάρχει κανένα πρόβλημα. Μπορούν και οι δύο να πειράξουν ό,τι θέλουν και δεν τρέχει κάστανο.

 

Όταν γίνει το merge του πρώτου θα πάνε όλα ok. Όταν ο maintainer πάει να κάνει merge το δεύτερο τότε ανάλογα τι αλλαγές υπήρχαν, μπορεί να υπάρχουν διενέξεις οι οποίες θα πρέπει να επιλυθούν. Αυτός είναι ο ένας τρόπος.

 

Είθισται όμως, αφού γίνει η συζήτηση και αποφασιστεί ότι το τάδε branch θα γίνει merge, ο dev που το έφτιαξε να το κάνει rebase. Δηλαδή φέρνει το νέο master (το οποίο αυτή τη στιγμή θα περιέχει τις αλλαγές που επέφερε το merge του πρώτου branch) και μετά κάνει rebase το δικό του branch πάνω στο νέο master. Αυτό θα έχει αποτέλεσμα μια σειρά διενέξεων επειδή όπως είπες οι δύο devs πείραζαν τα ίδια πράγματα.

 

Η διαφορά σε αυτό το τρόπο είναι ότι αντί να πρέπει να επιλύσει τις διενέξεις ο geomagas (maintainer) θα πρέπει να τις επιλύσεις εσύ (dev). Αυτό έχει δύο καλά. Αφενός αφαιρεί φορτίο από τον maintainer που έχει να κάνει merge 20 branches και αφετέρου γίνεται καλύτερη δουλειά γιατί εσύ έκανες τις αλλαγές οπότε γνωρίζεις πολύ καλά τι κάνουν αυτές οπότε μπορείς πιο εύκολα / σωστά να επιλύσεις τις διενέξεις από τον maintainer.

 

Το ποιος τρόπος χρησιμοποιείται συνήθως ορίζεται στην policy του project.

 

Μια 3η μου απορία είναι πως δεν έχω καταλάβει πως γίνεται γενικά ο συγχρονισμός στο git/github όταν δουλεύουν πολλοί ταυτόχρονα σε πράγματα που είναι κοινά.

Δεν κατάλαβα τι εννοείς εδώ.

 

Edit: το workflow που περιέγραψα σε πολλά μηνύματα είναι αυτό που λέει και ο pmav99 απλά δεν θα το εξήγησα καλά για αυτό δεν έγινε κατανοητό.

[pmav99]

@mifg1

 

1. Αν δεν είσαι commiter στο επίσημο repo δεν μπορείς.

 

2. Πρώτα θα κάνει merge τις αλλαγές του ενός και μετά του άλλου. Πιθανά, οι αλλαγές του δεύτερου να μην μπορούν να γίνουν merged automatically μόλις ενσωματωθούν οι αλλαγές του πρώτου (πχ αν έχουν αλλάξει και οι δύο την ίδια συνάρτηση) Σε αυτή την περίπτωση, ο main dev ίσως να ζητήσει από τον δεύτερο να κάνει rebase τις αλλαγες του στο τρέχον master (δηλαδή σε αυτό που έχουν ενσωματωθεί οι αλλαγές του πρώτου). Εν γένει αυτά συζητιούνται στους bug trackers.

 

3. Κάποιος πρέπει να αναλάβει να τα κάνει merge στο master.

[geomagas]

Σωστό δείχνει

 

Ευτυχώς, διότι για να συνδεθώ στο μηχάνημα απ' όπου τελικά το έκανα, ήθελα τρία ssh, ένα vpn και ένα πιστοποιητικό κοινωνικών φρονημάτων!

 

1. Αν δεν είσαι commiter στο επίσημο repo δεν μπορείς.

 

Είναι ο "Collaborator" στο github;

[pmav99]

Για να κάνεις μόνος σου αλλαγές σε ένα remote repository πρέπει να έχεις write privileges. Δηλαδή στη συγκεκριμένη περίπτωση πρέπει να μπορείς να κάνεις git push και το upstream σου να ειναι το official/blessed

[migf1]

Μέχρι τώρα πως το έκανες ? Πως έκανες τα REPLAY_NEXTMV, SaveLongReplays, ImproveComments ?

 

Όταν ένα branch που δημιούργησες τοπικά από το tortoise το κάνεις push αυτό φαίνεται στο github.

...

Ναι αλλά το κάνω push στο origin (στο fork μου δηλαδή), όχι στο blessed. Α, μάλλον τώρα το έπιασα... όταν κάνω pull-request οι υπόλοιποι το βλέπουν στην συζήτηση του blessed repo, κι έρχονται μετά και εξετάζουν το requested branch μου στο δικό μου fork, σωστά;

 

Edit: το workflow που περιέγραψα σε πολλά μηνύματα είναι αυτό που λέει και ο pmav99 απλά δεν θα το εξήγησα καλά για αυτό δεν έγινε κατανοητό.

Αν τα έχω καταλάβει καλά από ότι έχω διαβάσει περί github μέχρι στιγμής, ο pmav πρότεινε shared-repo-model, ενώ εμείς έχουμε τώρα fork+pull-request-model... έτσι δεν είναι;

 

Για τα υπόλοιπα σας ευχαριστώ και τους 2, το έπιασα

[pmav99]

Σκέψου ότι σε ένα μεγάλο project μπορείς να έχεις οργανωμένους τους devs σου σε ομάδες. Καθε dev έχει το δικό του local repo στον υπολογιστή του στο οποίο και αναπτύσσει τον κώδικα του. Κάθε ομάδα έχει το δικό της κεντρικό repository (team repo) το οποίο είναι το upstream του κάθε dev. Ένας από όλη την ομάδα είναι υπεύθυνος (team leader) για να κάνει merge τη δουλειά των devs στο κεντρικό repo της ομάδας (δηλαδή κάνει merge τα branches που κάνουν push οι devs της ομάδας).

 

Τώρα, πάνω από όλες τις ομάδες υπάρχει ένα κεντρικό repository (project repo) στο οποίο μαζεύονται οι αλλαγές όλων των ομάδων. Δηλαδή οι team leaders, αφού κάνουν merge τις αλλαγές τις ομάδας τους, κάνουν push σε κάποιο branch του project repo (δηλαδή το upstream των team repos είναι το project repo) Εκεί ο project leader επιβλέπει τις αλλαγές που του στέλνουν οι team leaders και τις κάνει merge (ή και όχι).

 

Κάπως έτσι δουλεύει ο linux kernel. Ο torvalds είναι στην κορυφή και από κάτω του είναι οι lieutenants. Φυσικά μπορείς να έχεις και περισσότερα stages. Δεν υπάρχει κάποιος περιορισμός· το μοντέλο μπορεί να κανει όσο scale θέλεις.

 

Σε πιο μικρά projects η οργάνωση σου σταματάει στο επίπεδο της ομάδας. Δηλαδή υπάρχει ένας (ή και περισσότεροι) team leader ο οποίος είναι υπεύθυνος για το τι μπαίνει και τι όχι στο κεντρικό repo. Οι διάφοροι devs έχουν ο καθένας τα δικά τους repositories. Τα pull requests είναι απλά ένας έξυπνος τρόπος για να ειδοποιείς τον team leader ότι έχεις κάνει αλλαγές και για να μπορέσει αυτός να τις κάνει review. Τα pull requests αποκτούν σημασία όταν ο team leader αποφασίσει ότι αξίζει να γίνουν merge. Τότε μόνο αλλάζει το team repo.

 

Για πρακτικούς λόγους, συμφέρει/βολεύει να έχεις περισσότερους του ενός team leaders (δηλαδή άτομα με commit rights). Μείνεται ο όγκος εργασίας, αλλά και το επίπεδο της γραφειοκρατίας.

 

 

Αν τα έχω καταλάβει καλά από ότι έχω διαβάσει περί github μέχρι στιγμής, ο pmav πρότεινε shared-repo-model, ενώ εμείς έχουμε τώρα fork+pull-request-model... έτσι δεν είναι;

Ναι

[geomagas]

@migf1: Αμ έπος αμ έργον: Σε έβαλα στους collaborators, οπότε μπορείς να αρχίσεις τα πειράματα

 

 

Αν και πιστεύω ότι πρέπει να είναι αντίστροφα τα πράγματα, καθώς το project δικαιωματικά ανήκει σε σένα. Όποια στιγμή θελήσεις, μου λες και στο κάνω transfer.

 

[imitheos]

Ναι αλλά το κάνω push στο origin (στο fork μου δηλαδή), όχι στο blessed. Α, μάλλον τώρα το έπιασα... όταν κάνω pull-request οι υπόλοιποι το βλέπουν στην συζήτηση του blessed repo, κι έρχονται μετά και εξετάζουν το requested branch μου στο δικό μου fork, σωστά;

Το "blessed" είναι κοινωνική ταμπέλα όχι τεχνική. Από τεχνικής άποψης όλα τα repo είναι το ίδιο. Θα μπορούσες κάλλιστα να το κάνεις push στο blessed απλά δεν έχεις δικαιώματα εγγραφής. Το πιο εύκολο θα είναι να κάνετε αυτό που πρότεινε ο pmav δηλαδή να οριστείς ως contributor στο repo του geomagas και να δουλεύετε κατευθείαν στο "blessed". Τότε θα κάνεις push κατευθείαν εκεί και θα φαίνεται στο blessed αντί για το fork σου.

 

Αν τα έχω καταλάβει καλά από ότι έχω διαβάσει περί github μέχρι στιγμής, ο pmav πρότεινε shared-repo-model, ενώ εμείς έχουμε τώρα fork+pull-request-model... έτσι δεν είναι;

Στο περίπου ναι έτσι είναι. Με το μοντέλο του pmav θα βγει το fork και θα δουλεύετε και οι δύο στο ίδιο και θα στέλνετε pull request για το τάδε branch του blessed αντί για forks.