Ingegneria del Software Corso di Laurea in Informatica per il Management (D)VCS. Davide Rossi Dipartimento di Informatica Università di Bologna

Size: px

Start display at page:

Download "Ingegneria del Software Corso di Laurea in Informatica per il Management (D)VCS. Davide Rossi Dipartimento di Informatica Università di Bologna"

Brittney Little
5 years ago
Views:

1 Ingegneria del Software Corso di Laurea in Informatica per il Management (D)VCS Davide Rossi Dipartimento di Informatica Università di Bologna

2 Rationale for version control Control the revisions of artifacts produced and modified during the development process Support team work

3 Historic perspective Local VCS 1972 SCCS 1982 RCS Client-server VCS 1990 CVS (client-server) 2000 SVN Distributed VCS 1990s TeamWare / 1998 BitKeeper 2003 Monotone / Darcs / 2006 Arch 2005 Bazaar / Mercurial / git

4 Basic principles The working copy The repository The files in the working copy that are not still in the repo or the files that differ from the last version of the same files in the repo Commit These are the versioned project files The pending changeset These are the project files as stored in the file system used by the development team Commit the pending changeset to the repo Update Align the working copy with the repo

5 Initial artifact [source: "Version Control by Example" by E. Sink]

6 Add [source: "Version Control by Example" by E. Sink]

7 Edit [source: "Version Control by Example" by E. Sink]

8 Delete [source: "Version Control by Example" by E. Sink]

9 Rename [source: "Version Control by Example" by E. Sink]

10 Move [source: "Version Control by Example" by E. Sink]

11 Status [source: "Version Control by Example" by E. Sink]

12 Diff [source: "Version Control by Example" by E. Sink]

13 Revert [source: "Version Control by Example" by E. Sink]

14 Log [source: "Version Control by Example" by E. Sink]

15 Tag [source: "Version Control by Example" by E. Sink]

16 Branch [source: "Version Control by Example" by E. Sink]

17 Merge [source: "Version Control by Example" by E. Sink]

18 Resolve [source: "Version Control by Example" by E. Sink]

19 Lock [source: "Version Control by Example" by E. Sink]

20 Centralized version control [Image credits: David Vega]

21 Centralized version control Each user works on a local copy A remote central repository is the single source of truth Working copies get in sync with the remote repo with updates and commits

22 Simple distributed version control [Image credits: David Vega]

23 Simple distributed version control Each user has a local repository Working copies are synced with the local repo using commits and updates Local repos are synced with the central repo using push and pull The central repo acts as the source of truth

24 Fully distributed version control [Image credits: David Vega]

25 Fully distributed version control Peer-to-peer Central repo could or could not exist No single source of truth

26 Branches A duplication of an object under source control Branches form hierarchies Child branch Parent (upstream) Trunk (parent less branch) Divergent branches can later be merged (i.e. integrated with an ancestor) A branched not intended to later be merged is usually called a fork

27 git A VCS designed to be Reliable High-performance Distributed Written in 2 weeks by Linus Torvalds (of course it then took several years for a fast hack to become a manageable application) Keyword: branching

28 git workflows Centralized Feature branch Gitflow

29 git centralized workflow [Image credits: atlassian.com]

30 git centralized workflow

31 When divergence occurs git pull --rebase origin master

32 When conflict occurs git add <some-file> git rebase --continue

33 Synchronization done - publish git push origin master

34 Feature branch workflow All feature development should take place in a dedicated branch Once the feature is completed the feature branch is pushed and a pull request is open Once the pull request is accepted the feature branch is merged

35 Gitflow workflow Two main (historical) branches: Master and Develop Feature branches derive from Develop (and are merged with it) When getting close to a release a Release branch is derived from Develop; no new feature are committed to a Release branch; when ready to ship Release is merged with Master

36 Gitflow workflow Hotfix branches are the only branches derived from Master; they are used for bug-fixing only and soon merged back

37 Conclusion A (D)VCS is the backbone of a software project All artifacts should be committed there (D)VCS can take some time to be mastered but learning how to use them is well-spent time

Version control CSE 403

Version control CSE 403 Goals of a version control system Keep a history of your work Explain the purpose of each change Checkpoint specific versions (known good state) Recover specific state (fix bugs,