The Information Technology have led us into an era where the production, sharing and use of information are now part of everyday life and of which we are often unaware actors almost: it is now almost inevitable not leave a digital trail of many of the actions we do every day; for example, by digital content such as photos, videos, blog posts and everything that revolves around the social networks (Facebook and Twitter in particular). Added to this is that with the "internet of things", we see an increase in devices such as watches, bracelets, thermostats and many other items that are able to connect to the network and therefore generate large data streams. This explosion of data justifies the birth, in the world of the term Big Data: it indicates the data produced in large quantities, with remarkable speed and in different formats, which requires processing technologies and resources that go far beyond the conventional systems management and storage of data. It is immediately clear that, 1) models of data storage based on the relational model, and 2) processing systems based on stored procedures and computations on grids are not applicable in these contexts. As regards the point 1, the RDBMS, widely used for a great variety of applications, have some problems when the amount of data grows beyond certain limits. The scalability and cost of implementation are only a part of the disadvantages: very often, in fact, when there is opposite to the management of big data, also the variability, or the lack of a fixed structure, represents a significant problem. This has given a boost to the development of the NoSQL database. The website NoSQL Databases defines NoSQL databases such as "Next Generation Databases mostly addressing some of the points: being non-relational, distributed, open source and horizontally scalable." These databases are: distributed, open source, scalable horizontally, without a predetermined pattern (key-value, column-oriented, document-based and graph-based), easily replicable, devoid of the ACID and can handle large amounts of data. These databases are integrated or integrated with processing tools based on the MapReduce paradigm proposed by Google in 2009. MapReduce with the open source Hadoop framework represent the new model for distributed processing of large amounts of data that goes to supplant techniques based on stored procedures and computational grids (step 2). The relational model taught courses in basic database design, has many limitations compared to the demands posed by new applications based on Big Data and NoSQL databases that use to store data and MapReduce to process large amounts of data. Course Website http://pbdmng.datatoknowledge.it/ Contact me to download the slides

1. An Introduction to GIT
Version Control with Git
Avoid to be the repository manager
Dr. Fabio Fumarola

2. Agenda
• What is Version Control? (and why use it?)
• What is Git? (And why Git?)
• How git works
• Create a repository
• Branches
• Add remote
• How data is stored
2

3. History
• Created by Linus Torvalds for work on the Linux
kernel ~2005
• Some of the companies that use git:
3

4. What is Git?

5. Git is a
DistributedVersion Control System

6. OR

7. Git is a
Content Management System

8. Git is a
history storage system

9. Git is a
content tracker

10. How ever you think about it…

11. How ever you think about it…

12. What is a Version Control
• Version Control - A system for managing changes made to
documents and other computer files
• What kinds of files can we use it with?
– Source code
– Documentation
– Short stories
– Binary files (music and pictures)
• What should we use it for?
– Text files
– Projects that have lots of revisions (changes)
– Collaborating
12

13. VCS Systems and their Operations
• Lots of different choices available:
– CVS
– SVN
– Perforce
– Git
– Mercurial (Hg), Bazaar
– And more!
• Most follow a repository model (though differ in how
the repositories work)
13

14. So why do we need a VCS?
• Our goals
– Share code (or something else) easily
– Keep track of any changes we make (and undo them with
ease)
– Maintain multiple versions of the same project/code base
– Clearly communicate what changes have been made
• There are two type of VCS
– Centralized and
– Distributed
14

15. Distributed vs Centralized
Centralized VCS
•One central repository
•Must be capable of
connecting to repo
•Need to solve issues with
group members making
different changes on the same
files
Distributed VCS
•Everyone has a working repo
•Faster
•Connectionless
•Still need to resolve issues,
but it's not an argument
against DVCS
15

16. Centralized vs Distributed
16
Central Server
Remote Server

17. Git file lifecycle
17

18. Creating our first repository
• Install git
• Establish our first repository:
– mkdir git-test
– cd git-test
– git init
• What do we have here?
– git status
18

19. Using our first repository
• Add a file
– touch file.txt
– git add file.txt
– git commit –m “add the first file”
19

20. Branching
• With Git we should embrace
the idea of branching
• Branching is the best method
to work with other in a
project
20

21. Branches Illustrated
master
A
> git commit –m ‘my first commit’> git commit –m ‘my first commit’

22. Branches Illustrated
master
> git commit (x2)> git commit (x2)
A B C

23. Branches Illustrated
bug123
master
> git checkout –b bug123> git checkout –b bug123
A B C

24. Branches Illustrated
master
> git commit (x2)> git commit (x2)
A B C
D E
bug123

25. Branches Illustrated
master
> git checkout master> git checkout master
A B C
D E
bug123

26. Branches Illustrated
bug123
master
> git merge bug123> git merge bug123
A B C D E

27. Branches Illustrated
master
> git branch -d bug123> git branch -d bug123
A B C D E

28. Branches Illustrated
master
A B C D E
F G
bug456

29. Branches Illustrated
master
A B C D E
F G
bug456
> git checkout master> git checkout master

30. Branches Illustrated
master
A B C D E
F G
> git merge bug456> git merge bug456
H
bug456

31. Branches Illustrated
master
A B C D E
F G
> git branch -d bug456> git branch -d bug456
H

32. Branches Illustrated
master
A B C D E
F G
bug456

33. Branches Illustrated
master
A B C D E
> git rebase master> git rebase master
F’ G’
bug456

34. Branches Illustrated
master
A B C D E
> git checkout master
> git merge bug456
> git checkout master
> git merge bug456
F’ G’
bug456

35. Branches Review
• Branches should be used to create “Features” in our
project
• Local branches are very powerful
• Rebase is not scary
35

36. Adding a remote
But, how we share our code with the other collaborators?
36
My Local
Repo
Tom’s Repo
Tracey’s
Repo
Matt’s
Repo
A B C
A B C A B C
A B C

37. Sharing commits
37
My Local
Repo
Tom’s Repo
Tracey’s
Repo
Matt’s
Repo
A B C
A B C A B C
A B C
Remote Repo
AA BB CC
D
D
D
D
DD

38. Setting up a Remote
• We can clone an existing repository
– git clone git@github.com:fabiofumarola/akka-tutorial.git
• We can push our changes
– git push
• We can pull friends change
– git pull
• We can also add a remote to an existing repository
– git remote add origin git@github.com:fabiofumarola/akka-
tutorial.git
38

39. Branches with remote
A
master
B C D E
bug123

40. Branches with remote
A
master
origin/master
B C D E
bug123

41. Branches with remote
A
BB CC DD EE
master
bug123
origin/master

42. Branches with remote
A
BB CC DD EE
master
bug123
FF GG
origin/master
origin/masterorigin/master

43. Branches with remote
A
BB CC DD EE
master
bug123
> git checkout master> git checkout master
origin/master

44. Branches with remote
A
BB CC DD EE
master
bug123
F G
> git pull origin> git pull origin
origin/master

45. Pull = Fecth + Merge
Fetch - updates your local copy of the remote
branch
Pull essentially does a fetch and then runs
the merge in one step.

46. Branches Illustrated
A
BB CC DD EE
master
bug123
F G
origin/master

47. Branches Illustrated
A
BB CC DD EE
master
bug123
F G
> git checkout bug123> git checkout bug123
origin/master

48. Branches Illustrated
A
B’B’ C’C’ D’D’ E’E’
master
bug123
F G
> git rebase master> git rebase master
origin/master

49. Branches Illustrated
A
B’B’ C’C’ D’D’ E’E’
master
bug123
F G
> git checkout master> git checkout master
origin/master

50. Branches Illustrated
A
master
bug123
F G
> git merge bug123> git merge bug123
B’B’ C’C’ D’D’ E’E’
origin/master

51. Branches Illustrated
A
master
F G
> git push origin> git push origin
B’ C’ D’ E’
bug123
origin/master

52. Push
Pushes your changes upstream
Git will reject pushes if newer changes exist
on remote.
Good practice: Pull then Push

53. Branches Illustrated
A
master
F G B’ C’ D’ E’
bug123
origin/master

54. Branches Illustrated
A
master
F G
> git branch -d bug123> git branch -d bug123
B’ C’ D’ E’
origin/master

55. Short vs. Long-Lived Branches
• We can use branch to:
– Solve bugs (hotfixes)
– Create features
– Make a release
• In order to simplify the management we can use:
– Git Flow: http://danielkummer.github.io/git-flow-
cheatsheet/index.it_IT.html

56. Branches Illustrated
E
master
origin/master

57. Branches Illustrated
E
master
origin/master
develop
> git branch develop> git branch develop

58. Branches Illustrated
E
master
origin/master
develop
> git push origin develop> git push origin develop
origin/develop

59. Branches Illustrated
E
master
origin/master
develop
> git checkout develop> git checkout develop
origin/develop

60. Branches Illustrated
E
master
origin/master
FF GG
develop
origin/develop

61. Branches Illustrated
E
master
origin/master
F G
develop
origin/develop
> git pull origin develop> git pull origin develop

62. Branches Illustrated
E
master
origin/master
F G
develop
origin/develop
> git checkout –b idea> git checkout –b idea
idea

63. Branches Illustrated
E
master
origin/master
F G
develop
origin/develop
> git commit> git commit
idea
H

64. Branches Illustrated
E
origin/master
F G
origin/develop idea
H
II
master
develop

65. Branches Illustrated
E
origin/master
F G
origin/develop idea
H
master
develop
> git pull (at least daily)> git pull (at least daily)
I

66. Branches Illustrated
E
origin/master
F G
origin/develop idea
H
master
> git checkout develop> git checkout develop
I
develop

67. Branches Illustrated
E
origin/master
F G
origin/develop idea
H
master
> git merge idea (fast forward merge)> git merge idea (fast forward merge)
I
develop

68. Branches Illustrated
E
origin/master
F G
origin/develop
H
master
> git branch –d idea> git branch –d idea
I
develop

69. Branches Illustrated
E
origin/master
F G
origin/develop
H
master
> git push origin develop> git push origin develop
I
develop

70. Merge Flow vs. Rebase Flow
E
origin/master
F G
origin/develop
H
master
> git push origin develop> git push origin develop
I
develop

71. Branches Illustrated – Merge Flow
E
origin/master
F G
origin/develop
H
master
> git checkout master> git checkout master
I
develop

72. Branches Illustrated – Merge Flow
E
origin/master
F G
origin/develop
H
master
> git merge develop> git merge develop
I
develop
J

73. Branches Illustrated – Merge Flow
E
origin/master
F G
origin/develop
H
master
> git push origin> git push origin
I
develop
J

74. Branches Illustrated – Rebase Flow
E
origin/master
F G
origin/develop
H
master
> git checkout master> git checkout master
I
develop

75. Branches Illustrated – Rebase Flow
E
origin/master
F G
origin/develop
H
master
> git rebase develop> git rebase develop
I’
develop
II

76. Branches Illustrated – Rebase Flow
E
origin/master
F G
origin/develop
H
master
> git push origin> git push origin
I’
develop

77. Rebase Flow
E
origin/master
F G
origin/develop
H
master
I’
develop
E
origin/master
F G
origin/develop
H
master
I
develop
J
Merge Flow

78. How Git stores data
• Git stores the content of each file in the tracking history
• Each time we do a commit it is made a copy of the file.
• However the content of each file is subject to revision for
conflicts (merge).
78

79. Git best practices for code collaboration
• When to commit?
– Source of major arguments (big changes vs small change)
– Never put broken code on the master branch (test first!)
– Try not to break things (don't do two weeks worth of work in one
commit)
– Always use a clear, concise commit message
– Put more details in lines below, but always make the first line short
– Describe the why; the what is clear in the change log
• When making giant changes, consider branches (we'll talk
about these in a few slides)
• Oh, and make sure your name and email are right
79

80. Supplemental

81. SSH
• Used to be most common transport for git
• Pros
– Allows reads and writes
– Authenticated network protocol
– Secure: data transfer is encrypted and authenticated
– Efficient: makes data as compact as possible
• Cons
– No anonymous read-only access

82. Sidebar: What is SSH?
• SSH is a protocol used for secure network
communication Getting files from github
• Generate public/private keys (ssh-keygen)
• Distribute public keys (add key to github)
• Someone (github) sends secure “message” (files) –
they encode with public key
• You receive the message/files – decode with
private key (only you know)
Putting files on github
• Process is reversed to send files to github
• You have the github public key (see
github_rsa.pub, in Documents and
Settings/Cyndi/.ssh on my machine)
• Use it to encode when sending
• github uses their private key to decode