Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Version Control Systems: Git PowerPoint Presentation
Download Presentation
Version Control Systems: Git

Version Control Systems: Git

91 Views Download Presentation
Download Presentation

Version Control Systems: Git

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Version Control Systems: Git Αλέξανδρος Χατζηγεωργίου – Μεταπτυχιακό Πρόγραμμα Σπουδών, Τμ. Εφαρμοσμένης Πληροφορικής, 2012

  2. Version Control System • Ένα σύστημα ελέγχου εκδόσεων (version control system VCS – ή revision control system) είναι λογισμικό που επιτρέπει τη διαχείριση και παρακολούθηση αλλαγών που συμβαίνουν σε οποιοδήποτε έγγραφο ενός έργου

  3. Version Control System • Οφέλη από τη χρήση VCS: • - Backup • Οργάνωση αρχείων που έχουν δημιουργηθεί σε διαφορετικές χρονικές στιγμές (χωρίς συμβάσεις για ονοματοδοσία φακέλων βάσει ημερομηνίας) • θα μπορούσα να κάνω “Save As..” σε διαφορετικό φάκελο κάθε φορά, να συμπιέζω για να κερδίσω χώρο….χρονοβόρο και κουραστικό • Ανάκτηση προηγούμενων εκδόσεων και σύγκριση μεταξύ εκδόσεων (εξοικονόμηση χώρου εγγυημένη..) • αν έχω μια συλλογή αρχείων που αποτελούν ένα έργο (πηγαίος κώδικας, βιβλιοθήκες, εικόνες κλπ) θα πρέπει να αρχειοθετώ ένα ολόκληρο directory κάθε φορά…..!

  4. Version Control System • Οφέλη από τη χρήση VCS: • Διατήρηση log για τις αλλαγές που έχουν γίνει • εναλλακτικά θα έπρεπε να έχω ένα αρχείο στο οποίο να καταγράφω στοιχεία για κάθε αλλαγή που γίνεται • Δυνατότητα εργασίας πολλών ατόμων επί του ιδίου έργου, ανεξαρτήτως της γεωγραφικής τους θέσηςή χρονικής στιγμής • εναλλακτικά θα έπρεπε να αποθηκεύω σε κοινόχρηστο φάκελο ενημερώνοντας τους συναδέλφους για το πότε μπορούν να δουλέψουν επί ενός αρχείου

  5. Version Control System • In a VCS: • Files cannot be overwritten • There is a common repository that holds all the latest files • Allows you to revert back to an older version of the file/project if needed • Allows you to inspect differences (diff) between versions

  6. Version Control System • Οφέλη από τη χρήση VCS: • Διαχείριση συγκρούσεων Suppose Alice modifies class A, and Bob modifies class B. Theyboth upload their changes. Most systems will automatically deduce a reasonable course of action: acceptand merge their changes, so both Alice’s and Bob’s edits are applied. Now suppose both Alice and Bob have made distinct edits to the same line. Then it is impossible toproceed without human intervention. The second person to upload is informed of a merge conflict, andmust choose one edit over another, or revise the line entirely. More complex situations can arise. Version control systems handle the simpler cases themselves, andleave the difficult cases for humans.

  7. Git • Το Git είναι ένα κατανεμημένο σύστημα ελέγχου εκδόσεων (distributed version control system – DVCS) που σημαίνει ότι επιτρέπει την παράλληλη εργασία πολλαπλών ατόμων σε ένα έργο ακόμα και χωρίς την ύπαρξη σύνδεσης σε κεντρικό δίκτυο. Η εργασία τους μπορεί να καταχωρηθεί (push) στο έργο όταν είναι έτοιμη.

  8. Centralized vs. Distributed each action has to pass through the network  —  leaving a developer unable to work if they happen to have no network connection

  9. Centralized vs. Distributed In distributed systems, each developer has their own full-fledged repository on their computer. In most set-ups there’s an additional central repository on a server that’s used for sharing. However, this is not a requirement; every developer can perform all important actions in their local repository: committing changes, viewing differences between revisions, switching branches, etc

  10. Git • Git is an open source project, that has been active for several years and is written mostly in C

  11. Git • Eclipse usage: Project & code repository breakdown as of 2012-03-25

  12. Git popularity • Google Trends (blue: Git, red: svn)

  13. Git • Operations (local)

  14. Git • Operations (with remote)

  15. Git Workflow Subversion-Style Workflow A centralized workflow is very common, especially from people transitioning from a centralized system. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

  16. Git Workflow Integration Manager: single person who commits to the “blessed” repository

  17. Git Workflow Dictator and Lieutenants Workflow For more massive projects, a development workflow like that of the Linux kernel is often effective. In this model, some people ('lieutenants') are in charge of a specific subsystem of the project and they merge in all changes related to that subsystem. Another integrator (the 'dictator') can pull changes from only his/her lieutenants and then push to the 'blessed' repository that everyone then clones from again.

  18. Prerequisites • Install EGit • Create a project in a remote repository (e.g. GitHub) • Put project under version control

  19. Basic Usage

  20. Basic Usage retrieved from “Git the basics”, B. Trojanowski, 2008

  21. Basic Usage

  22. Basic Usage

  23. Basic Usage

  24. Basic Usage

  25. Basic Usage

  26. Basic Usage

  27. Git internally…

  28. Git internally…

  29. Git internally…

  30. Git internally…

  31. Branching • Έστω ότι εργαζόμαστε σε ένα έργο και έχουμε ήδη πραγματοποιήσει ορισμένα commit

  32. Branching • Αποφασίζουμε να εργαστούμε επάνω στο πρόβλημα #53 και για το λόγο αυτό θέλουμε να δημιουργήσουμε ένα καινούργιο κλάδο (branch) στον οποίο να επιλύσουμε το πρόβλημα

  33. Branching • Αφού κάνουμε ορισμένες αλλαγές (σχετικά με το πρόβλημα) πραγματοποιούμε ένα commit. Η ενέργεια αυτή «προχωρά» τον κλάδο iss53 προς τα εμπρός.

  34. Branching • Στην πορεία γίνεται γνωστό ότι κάτι πρέπει να διορθωθεί άμεσα στο λογισμικό που υπήρχε. Επειδή οι αλλαγές στο πρόβλημα #53 δεν έχουν ολοκληρωθεί επιστρέφουμε στον κλάδο «master». • Στο σημείο αυτό, η δομή του working directory είναι ως είχε

  35. Branching • Δημιουργούμε έναν καινούργιο κλάδο (hotfix) και διορθώνουμε το πρόβλημα που υπήρχε και καταχωρούμε τις αλλαγές κάνοντας ένα νέο commit.

  36. Branching • Αφού βεβαιωθούμε ότι η λύση είναι σωστή συγχωνεύουμε (merge) τον κλάδο hotfix επί του κλάδου master. • Η συγχώνευση είναι εύκολη (fast-forward) δεδομένου ότι το hotfix είχε «χτιστεί» επί του master. Η συγχώνευση συνίσταται απλά στην προώθηση του δείκτη “merge”

  37. Branching • O κλάδος hotfix μπορεί πλέον να διαγραφεί • επιστρέφουμε στον κλάδο (‘switch to’) iss53. • Κάνουμε τις αλλαγές και commit

  38. Branching • Υποθέτοντας ότι το πρόβλημα #53 επιλύθηκε πλήρως, αποφασίζεται η συγχώνευσης της λύσης στο master branch • Η συγχώνευση εδώ είναι δυσκολότερη(three-way merge)

  39. Branching • Αν δεν συναντηθούν conflicts και η συγχώνευση γίνει αυτόματα θα προκύψει η εξής εικόνα του συστήματος:

  40. Branching • Conflicts θα δημιουργηθούν εάν έχουν τροποποιηθεί ίδια σημεία στο ίδιο αρχείο. O προγραμματιστής θα πρέπει να επιλύσει το conflict κάνοντας add το αντίστοιχο αρχείο για να υποδηλώσει την ολοκλήρωση του merging

  41. Reading Stuff • Git with Eclipse (EGit) Tutorial: http://www.vogella.com/articles/EGit/article.html • EGit tutorial: http://unicase.blogspot.gr/2011/01/egit-tutorial-for-beginners.html • Top 10 Git Tutorials: http://sixrevisions.com/resources/git-tutorials-beginners/ • Pro Git Book: http://git-scm.com/book