path: root/usth/ICT2.7/P1L4 Version Control Subtitles/12 - GIT Workflow - lang_en_vs5.srt

1
00:00:00,070 --> 00:00:02,100
But before jumping into the demo I would like

2
00:00:02,100 --> 00:00:05,370
to give a high level overview of the GIT workflow,

3
00:00:05,370 --> 00:00:08,420
which will help you better, following the demo. So let

4
00:00:08,420 --> 00:00:12,480
me start by representing four fundamental elements in the GIT

5
00:00:12,480 --> 00:00:15,640
workflow which are these four: the workspace which is your

6
00:00:15,640 --> 00:00:19,980
local directory. The index, also called the stage, and we'll

7
00:00:19,980 --> 00:00:22,470
see in a minute what the index is. Then, we

8
00:00:22,470 --> 00:00:25,380
have the local repository. We'll also refer to this as

9
00:00:25,380 --> 00:00:27,910
HEAD in the, when we explain the different commands

10
00:00:27,910 --> 00:00:31,340
and then, the word flow. And finally, the remote repository.

11
00:00:31,340 --> 00:00:34,600
If you consider a file in your work space it

12
00:00:34,600 --> 00:00:37,860
can be in three possible states. It can be committed

13
00:00:37,860 --> 00:00:40,170
which means that the data, the latest changes to the

14
00:00:40,170 --> 00:00:45,030
file are safely stored here. It could be modified, which

15
00:00:45,030 --> 00:00:47,840
is the case of the file being changed and no,

16
00:00:47,840 --> 00:00:50,710
none of these changes being saved to the local repository

17
00:00:50,710 --> 00:00:54,440
so locally modified or it can be staged. And

18
00:00:54,440 --> 00:00:58,270
stage means that the file is basically part of this

19
00:00:58,270 --> 00:01:01,620
index. And what that means, that it's been tagged

20
00:01:01,620 --> 00:01:04,890
to be considered in the next commit. And I know

21
00:01:04,890 --> 00:01:08,070
that this is not all 100% intuitive, so let's

22
00:01:08,070 --> 00:01:10,860
look at that again by considering the actual workflow and

23
00:01:10,860 --> 00:01:12,680
let's see what happens when you issue the different

24
00:01:12,680 --> 00:01:16,060
commands in git. So the first command that you normally

25
00:01:16,060 --> 00:01:18,520
run in case you, you're getting access to a remote

26
00:01:18,520 --> 00:01:21,940
repository, is the git clone command. And the git clone,

27
00:01:21,940 --> 00:01:24,880
followed by the url for that repository, will create a

28
00:01:24,880 --> 00:01:28,580
local copy of the repository in your workspace. And of

29
00:01:28,580 --> 00:01:30,310
course, you don't have to do this step if you're

30
00:01:30,310 --> 00:01:34,380
creating the repository yourself. The next command that we already

31
00:01:34,380 --> 00:01:38,170
saw is the command add. And what the command add

32
00:01:38,170 --> 00:01:41,130
does is to add a file that is in the

33
00:01:41,130 --> 00:01:44,630
workspace to this index. And we say that after that, the

34
00:01:44,630 --> 00:01:48,700
file is staged. So it's marked to be committed, but not

35
00:01:48,700 --> 00:01:53,350
yet committed. And here I'm just mentioning this minus u option.

36
00:01:53,350 --> 00:01:56,330
If you specify the minus u option, you will also consider deleted

37
00:01:56,330 --> 00:01:58,820
files File, but let's not get there for now, we'll talk

38
00:01:58,820 --> 00:02:01,240
about that when we do the demo. As I said, if you

39
00:02:01,240 --> 00:02:03,720
add the file, it just gets added to this index but

40
00:02:03,720 --> 00:02:06,430
is not actually committed, so what you need to do, is to

41
00:02:06,430 --> 00:02:10,389
commit the file, so when you execute git commit, all the

42
00:02:10,389 --> 00:02:13,970
files that are staged, that are released it here, their changes

43
00:02:13,970 --> 00:02:17,080
will be committed to the local repository. So your files, as

44
00:02:17,080 --> 00:02:18,970
I was saying, they can be in three states. They will

45
00:02:18,970 --> 00:02:21,820
go from the modified state to the stage state when you

46
00:02:21,820 --> 00:02:24,200
execute the app. And then from the stage state to the

47
00:02:24,200 --> 00:02:27,510
committed state when you perform a GIT Commit. Okay, so at

48
00:02:27,510 --> 00:02:31,780
this point your changes are safely stored in the local repository.

49
00:02:31,780 --> 00:02:34,370
Notice that you can also perform these two steps at

50
00:02:34,370 --> 00:02:38,150
once by executing a Commit -a. So if you have

51
00:02:38,150 --> 00:02:40,920
a set of modified files, and all these files are

52
00:02:40,920 --> 00:02:44,550
already part of the repository, so they're already known to diversion

53
00:02:44,550 --> 00:02:47,540
control system, you can simply execute a commit -a.

54
00:02:47,540 --> 00:02:50,040
And what the commit -a command will do, it

55
00:02:50,040 --> 00:02:53,080
will stage your file and then commit them. All at

56
00:02:53,080 --> 00:02:56,650
once. So it's a convenient shortcut. Of course, as I said,

57
00:02:56,650 --> 00:02:58,710
this will not work if the file is a new file.

58
00:02:58,710 --> 00:03:00,730
So if a file is a new file, you have to manually add

59
00:03:00,730 --> 00:03:04,620
it. Otherwise commit -a will just stage and commit at once.

60
00:03:04,620 --> 00:03:07,400
As we discussed when we looked at the diffence between centralized

61
00:03:07,400 --> 00:03:10,520
and decentralized version console system. We saw that in the case

62
00:03:10,520 --> 00:03:13,930
of the decentralized, there is a local repository which is this one.

63
00:03:13,930 --> 00:03:17,190
And then you have to explicitly push your changes to a remote

64
00:03:17,190 --> 00:03:21,850
repository, and this is exactly what the git push command does. It pushes

65
00:03:21,850 --> 00:03:25,930
your changes that are in the local repository to the remote repository

66
00:03:25,930 --> 00:03:28,160
so at this point all of your changes will be

67
00:03:28,160 --> 00:03:31,680
visible to anyone who has access to the remote repository.

68
00:03:31,680 --> 00:03:33,710
Now, let's see the opposite flow so how does it

69
00:03:33,710 --> 00:03:36,640
work when you're actually getting files from the repository instead

70
00:03:36,640 --> 00:03:39,650
of committing files to the repository. So the first command

71
00:03:39,650 --> 00:03:43,280
I want to mention is the get fetch command and

72
00:03:43,280 --> 00:03:46,900
what the get fetch command does is to get files from

73
00:03:46,900 --> 00:03:50,680
the remote repositories to your local repository, but not yet to

74
00:03:50,680 --> 00:03:53,890
your working directory. And we will see what is the usefullness of

75
00:03:53,890 --> 00:03:56,900
doing this operation. Of having the files all in the local respository,

76
00:03:56,900 --> 00:03:59,380
but not in your local directory. So, what that means, just to

77
00:03:59,380 --> 00:04:01,360
make sure that we're on the same page. Is that you

78
00:04:01,360 --> 00:04:05,620
will not see these files when you workspace. You will still have

79
00:04:05,620 --> 00:04:09,030
your local files here. So this is sort of a physical distinction.

80
00:04:09,030 --> 00:04:12,060
In order to get your data files from the local repositories to

81
00:04:12,060 --> 00:04:14,470
your workspace you have to issue another command. Which is

82
00:04:14,470 --> 00:04:18,250
the command git merge. Git merge will take the changes in

83
00:04:18,250 --> 00:04:21,870
local repository and get them to your local workspace. So at

84
00:04:21,870 --> 00:04:25,460
this point your files will be updated. To what is in

85
00:04:25,460 --> 00:04:27,730
the remote reposity. Or at least what was in the

86
00:04:27,730 --> 00:04:30,810
remote reposity at the time of the fetch. SImilarly to what

87
00:04:30,810 --> 00:04:34,340
happened for the add and commit. There's a shortcut which is

88
00:04:34,340 --> 00:04:37,230
the command git pull. So in case you want to get

89
00:04:37,230 --> 00:04:40,590
the changes directly. To your work space with a single

90
00:04:40,590 --> 00:04:44,120
command, you can issue a git pull command and what will

91
00:04:44,120 --> 00:04:46,560
happen, is that the changes will get collected from the

92
00:04:46,560 --> 00:04:49,810
remote repository and they will go to your local repository and

93
00:04:49,810 --> 00:04:51,990
to your work space, at once. So this has the

94
00:04:51,990 --> 00:04:55,820
same affect as performing a git fetch and a git merge.

95
00:04:55,820 --> 00:04:59,160
So if we can do everything in one command, why,

96
00:04:59,160 --> 00:05:03,290
why we want to fetch and berch as two separate operations?

97
00:05:03,290 --> 00:05:05,920
So one of the reason is because this allows us

98
00:05:05,920 --> 00:05:09,410
to compare files before we actually get the latest version

99
00:05:09,410 --> 00:05:12,600
of the files. In particular, I can run the command

100
00:05:12,600 --> 00:05:17,310
git diff head to get the difference between my local files,

101
00:05:17,310 --> 00:05:20,330
the files in my working directory, and the files in

102
00:05:20,330 --> 00:05:22,800
my local repository. So what I can do, I can

103
00:05:22,800 --> 00:05:25,550
fetch the files from the remote repository, and once I

104
00:05:25,550 --> 00:05:29,260
fetch these files. I can run a git diff head and

105
00:05:29,260 --> 00:05:32,620
check what the differences are. And based on the differences decide

106
00:05:32,620 --> 00:05:35,554
whether I want to merge or not. So while we are talking about

107
00:05:35,554 --> 00:05:37,890
git diff, there is something else that you can use with the

108
00:05:37,890 --> 00:05:41,060
diff command. So what you can do, you can run git diff

109
00:05:41,060 --> 00:05:44,930
without further specifying head. In this case, what the command tell you

110
00:05:44,930 --> 00:05:48,310
is the difference between the files that you have in your work

111
00:05:48,310 --> 00:05:51,780
space and the ones that are staged for a commit. So basically,

112
00:05:51,780 --> 00:05:54,630
what it will be telling you, is that what you could still

113
00:05:54,630 --> 00:05:58,300
add to the stage for the further commit, and that you

114
00:05:58,300 --> 00:06:01,230
haven't already. So what local changes will not make it to the

115
00:06:01,230 --> 00:06:04,440
next commit, basically. And this you can use, for example, as

116
00:06:04,440 --> 00:06:07,450
a sanity check before doing a commit to make sure all the

117
00:06:07,450 --> 00:06:09,980
local changes that you have, and that you want to commit,

118
00:06:09,980 --> 00:06:13,230
are actually staged and therefore will be considered. So now we will

119
00:06:13,230 --> 00:06:16,930
cover all of the commands that we saw here. In our practical

120
00:06:16,930 --> 00:06:20,560
demo. But please feel free to refer back to this Git Workflow

121
00:06:20,560 --> 00:06:23,570
to get a kind of a high level vision. Or maybe you want to keep it next to

122
00:06:23,570 --> 00:06:26,110
you, because this really gives you the overall structure

123
00:06:26,110 --> 00:06:28,450
and the overall view of what happens when you

124
00:06:28,450 --> 00:06:31,160
run the different commands. And it also helps you

125
00:06:31,160 --> 00:06:34,840
visualize The different elements that are relevant when you're

126
00:06:34,840 --> 00:06:37,970
using GIT. So the workspace, once more, the index

127
00:06:37,970 --> 00:06:40,790
or stage, the local repository, and the remote repository.