Version Control Systems: Git. Αλέξανδρος Χατζηγεωργίου – Μεταπτυχιακό Πρόγραμμα Σπουδών, Τμ. Εφαρμοσμένης Πληροφορικής, 2012. Version Control System.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Αλέξανδρος Χατζηγεωργίου – Μεταπτυχιακό Πρόγραμμα Σπουδών, Τμ. Εφαρμοσμένης Πληροφορικής, 2012
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.
each action has to pass through the network — leaving a developer unable to work if they happen to have no network connection
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
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.
Integration Manager: single person who commits to the “blessed” repository
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.
retrieved from “Git the basics”, B. Trojanowski, 2008