508 lines
12 KiB
Plaintext
508 lines
12 KiB
Plaintext
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.
|