Όταν νομίζεις ότι ξέρεις GitHub και παθαίνεις black out

[Dinos_12345]

Είμαι σε μια ομάδα 5 ατόμων. Θέλουμε να κάνουμε ένα project σε Rails, και το έχουμε βάλει σε ένα private repo που έχουμε όλοι write access. Πώς στο καλό να κάνουμε τις αλλαγές μας χωρίς να κάνουμε direct commits στο master και χωρίς να λιώσουμε στο conflict resolution;

 

Σκέφτομαι να χρησιμοποιήσουμε GitHub Flow, αλλά έχω μπερδευτεί με τα branches και πως να κάνουμε merge σωστά.

Thanks

[ChRis6]

Commit κάνεις στο τοπικό σου branch. Στο github κάνεις push.

Για να μην χαλάσει το master (ή οποιοδήποτε άλλο) πρώτα git pull και μετά git push.

[Ilias95]

Τοπικά πάντα δουλεύετε το οτιδήποτε σε topic branches.
Μόλις κάτι είναι έτοιμο δύο επιλογές.

1. Φτιάχνετε ένα patch κατευθείαν από το τοπικό branch και το ανεβάζετε κάπου για review. Αν περάσει το review κάποιος το κάνει apply στο main repo.

 

2. Ο καθένας έχει και ένα δικό του "fork" στο github όπου κάνει push τα topic branches του. Έπειτα μέσα από το interface του github είναι εύκολο να κάνεις pull request στο main repo. Αν οι αλλαγές περάσουν το review, το github μπορεί να κάνει εύκολα το merge μόνο του συνήθως.

Σε κάθε περίπτωση είναι καλό να βάλετε κάποιον κανόνα του στυλ "τίποτα δεν γίνεται merge στο main repo αν δεν δώσουν ack τουλάχιστον 2 άτομα (διαφορετικά από τον author)".

[Predatorkill]

Dinos αυτο δεν ειναι blackout, αυτο που επαθα εγω προχτες ειναι το αληθινο black out, την ωρα του commit να πεφτει το ρευμα απο τη κακοκαιρια (να το χεσω το ups) και να γινεται ολο το local corrupted. Μη τυχει σε κανεναν σας!

 

Μολις ειδα το blackout στο τιτλο ειπα κι αλλος το παθε ρε πουστη

[MeTaXaS4]

το github flow σου λέει στην ουσία ότι θα έχεις ένα branch για κάθε feature, fix, release που θέλεις να αναπτύξεις/διορθώσεις.
Θα μπορούσατε να έχετε ότι έχει στο master να είναι το live, develop ότι έρχεται από τα feature,fix,release branches. 

όταν τελειώσει κάποιος με το εκάστοτε feature/fix μπορεί να ανοίξει ένα merge request κάνετε οι υπόλοιποι review και το προσθέτε στο develop branch και μετά οι υπόλοιποι κάνετε pull στα άλλα branches που δουλεύετε.

[Dinos_12345]

Nice, got it. Διάβασα λίγα workflow example και κατέληξα σε αυτό του GItHubflow, όπου για να κάνουμε merge στο master κάνουμε 

git merge --squash <branch name> και μετά ένα git commit, ώστε να φανεί μόνο ένα record στο master.

[SakislolGR]

Από την μικρή μου επαγγελματική εμπειρία δεν έχει τύχει να δουλέψουμε όλοι μαζί σε 1 Project

 

Έχω μια απορία.

 

Έστω ότι είναι 3 άτομα σε 1Project. Ο καθένας κάνει ότι κάνει στο forked του και κάνει commit locally. Μετά κάνει Pull Request στον Master... 

 

ωραία μέχρι εδώ...

 

αν όμως αυτό που κάνει ο Α εξαρτάται από τον Β?

 

Έστω ότι αυτοί φτιάχνουν μια εφαρμογή Android και έχουν έναν nooba πρακτικάριο που του δίνουν να φτιάχνει τα Layouts (xmls).

• Ο Α φτιάχνει τα xml
• Ο Β φτιάχνει τον κώδικα, τα adapters κλπ

Ο Β εξαρτάται από τον Α για να ολοκληρώσει. Τι θα κάνει? θα φτιάξει τον Adapter στο περίπου με errors ή θα περιμένει τον Α να τελειώσει και μετά να κάνει Sync (να κατεβάσει το χμλ στο φορκετ του)

 

Μπορεί το παραπάνω παράδειγμα να είναι πολύ απλό καθώς ένα xml είναι 10 λεπτά υπόθεση (λέμε τώρα). Αν όμως και οι 2 έχουν κώδικα, και ο κώδικας του Α εξαρτάται από του Β...

[MeTaXaS4]

ναι αλλά για να ξεκινήσει ο Β δεν θα πρέπει να έχει τελειώσει ο Α στο διάγραμμα Gantt σου ; 
Η απάντηση είναι ναι, οπότε που το πρόβλημα με τα forks? απλά ο Β πρέπει να κάνει pull την δουλειά του A.

[Dinos_12345]

Με ένα φίλο που κάναμε πάλι μαζί ένα project, εκείνος είχε φτιάξει ένα dummy cli για να τρέχει τα κομμάτια του, μου τα έδινε εμένα μετά και τα βάζαμε στο main πρόγραμμα. Αυτό όμως χωρίς GitHub, πριν ένα χρόνο. Έτσι θα μπορούσε να δουλέψει το παράδειγμα που ανέφερε ο παραπάνω, ο Β κάνει ένα test ui και παίζει με τα δικά του, μετά το βάζει στου Α. Δεν ξέρω πόσο αποτελεσματικό είναι όμως αυτό

[Predatorkill]

Ντινο βρες ενα καλο tutorial git ή github και θα σου λυθουν ολες οι αποριες με παραδειγματα συν κι αλλα που προκυπτουν οταν εργαζονται πολλοι σε ενα repo.