1096 lines
26 KiB
Plaintext
1096 lines
26 KiB
Plaintext
1
|
|
00:00:00,120 --> 00:00:02,170
|
|
In this first part of the git demo, we will
|
|
|
|
2
|
|
00:00:02,170 --> 00:00:05,080
|
|
call it the basics of git. So for example, how to
|
|
|
|
3
|
|
00:00:05,080 --> 00:00:08,280
|
|
introduce yourself to git, how to create a repository, how to
|
|
|
|
4
|
|
00:00:08,280 --> 00:00:12,450
|
|
commit changes and get changes from the repository, and so on.
|
|
|
|
5
|
|
00:00:12,450 --> 00:00:15,140
|
|
So after you installed git you should have the git tool
|
|
|
|
6
|
|
00:00:15,140 --> 00:00:18,150
|
|
available on the command line, so you can run the command
|
|
|
|
7
|
|
00:00:18,150 --> 00:00:21,110
|
|
git and, if you just execute git you will get the
|
|
|
|
8
|
|
00:00:21,110 --> 00:00:25,930
|
|
usage information for git, with the most commonly used git commands.
|
|
|
|
9
|
|
00:00:25,930 --> 00:00:28,940
|
|
And to find information on any command, you can simply
|
|
|
|
10
|
|
00:00:28,940 --> 00:00:32,310
|
|
type git help and the name of the command. For
|
|
|
|
11
|
|
00:00:32,310 --> 00:00:35,240
|
|
example, lets try to write git help init. And that
|
|
|
|
12
|
|
00:00:35,240 --> 00:00:38,960
|
|
brings up the git manual page for git init, which describes
|
|
|
|
13
|
|
00:00:38,960 --> 00:00:41,590
|
|
the command, the synopsis, and so on. Now, lets get
|
|
|
|
14
|
|
00:00:41,590 --> 00:00:45,970
|
|
started with using git by introducing ourselves to git, which is
|
|
|
|
15
|
|
00:00:45,970 --> 00:00:47,830
|
|
the first thing we need to do. To do that
|
|
|
|
16
|
|
00:00:47,830 --> 00:00:51,310
|
|
we use the git config command, in particular we are going to
|
|
|
|
17
|
|
00:00:51,310 --> 00:00:54,170
|
|
write to the git config minus, minus global
|
|
|
|
18
|
|
00:00:54,170 --> 00:00:56,440
|
|
user dot name. Which means we are telling it
|
|
|
|
19
|
|
00:00:56,440 --> 00:00:59,900
|
|
our user name. We'll specify our user name which
|
|
|
|
20
|
|
00:00:59,900 --> 00:01:02,970
|
|
in this case is George P. Burdell. You could
|
|
|
|
21
|
|
00:01:02,970 --> 00:01:04,970
|
|
also provide your email address in the same
|
|
|
|
22
|
|
00:01:04,970 --> 00:01:09,370
|
|
way. So you still use the git config --global
|
|
|
|
23
|
|
00:01:09,370 --> 00:01:12,750
|
|
command. But in this case you will write user.email
|
|
|
|
24
|
|
00:01:12,750 --> 00:01:16,580
|
|
as the property. And then you'll specify a suitable
|
|
|
|
25
|
|
00:01:16,580 --> 00:01:19,670
|
|
email address. In this case, the email address of George P.
|
|
|
|
26
|
|
00:01:19,670 --> 00:01:23,780
|
|
Burdell. We will now look at some commonly used commands that to
|
|
|
|
27
|
|
00:01:23,780 --> 00:01:27,210
|
|
create and maintain a local repository. Let's first create a
|
|
|
|
28
|
|
00:01:27,210 --> 00:01:30,510
|
|
new project and call it my project. So, to do that we
|
|
|
|
29
|
|
00:01:30,510 --> 00:01:32,790
|
|
are simply going to create a directory and then we're going
|
|
|
|
30
|
|
00:01:32,790 --> 00:01:35,520
|
|
to move into that directory. Now, if we try to call the
|
|
|
|
31
|
|
00:01:35,520 --> 00:01:39,000
|
|
git status command at this point to see what's the state of
|
|
|
|
32
|
|
00:01:39,000 --> 00:01:41,990
|
|
my project, of course git doesn't know anything about this project, right?
|
|
|
|
33
|
|
00:01:41,990 --> 00:01:44,360
|
|
So, you will get an error. It will tell you that, basically,
|
|
|
|
34
|
|
00:01:44,360 --> 00:01:47,080
|
|
we're not in a git repository. So how do we create a git
|
|
|
|
35
|
|
00:01:47,080 --> 00:01:50,090
|
|
repository? How do we make this? A Git repository, but we do it
|
|
|
|
36
|
|
00:01:50,090 --> 00:01:53,560
|
|
by calling git init and the output will tell you that the
|
|
|
|
37
|
|
00:01:53,560 --> 00:01:56,580
|
|
repository was initialized. If we check the status again, you will see
|
|
|
|
38
|
|
00:01:56,580 --> 00:01:59,790
|
|
that now Git recognizes the repository and will tell you that there is
|
|
|
|
39
|
|
00:01:59,790 --> 00:02:01,160
|
|
nothing to commit because, of course,
|
|
|
|
40
|
|
00:02:01,160 --> 00:02:03,190
|
|
the repository is completely empty. So let's
|
|
|
|
41
|
|
00:02:03,190 --> 00:02:07,380
|
|
just create a new, empty file. Which we're going to call REAME. So
|
|
|
|
42
|
|
00:02:07,380 --> 00:02:10,008
|
|
now if you run git status, as you can see, git will
|
|
|
|
43
|
|
00:02:10,008 --> 00:02:13,250
|
|
tell you there is a file that's called README, but it's untracked.
|
|
|
|
44
|
|
00:02:13,250 --> 00:02:15,600
|
|
Now what that means is that the file not staged, if you
|
|
|
|
45
|
|
00:02:15,600 --> 00:02:18,710
|
|
remember our lesson. So what we need to do, we first need
|
|
|
|
46
|
|
00:02:18,710 --> 00:02:22,040
|
|
to tell git that, you know, this needs to be considered. And
|
|
|
|
47
|
|
00:02:22,040 --> 00:02:25,690
|
|
the way we do that, is by calling the git at command
|
|
|
|
48
|
|
00:02:25,690 --> 00:02:28,880
|
|
and then we specify README as the argument for the command. If
|
|
|
|
49
|
|
00:02:28,880 --> 00:02:33,090
|
|
we call again, Git status. Now, as you can see, Git knows
|
|
|
|
50
|
|
00:02:33,090 --> 00:02:35,780
|
|
that there is a new file called README, because the file
|
|
|
|
51
|
|
00:02:35,780 --> 00:02:38,390
|
|
is staged. So Git is aware of the fact that this
|
|
|
|
52
|
|
00:02:38,390 --> 00:02:41,490
|
|
file has to be committed. So, to commit a file,
|
|
|
|
53
|
|
00:02:41,490 --> 00:02:45,410
|
|
we simply execute git commit, which will open a text editor, which
|
|
|
|
54
|
|
00:02:45,410 --> 00:02:48,500
|
|
can be different, depending on what is your environment, and here
|
|
|
|
55
|
|
00:02:48,500 --> 00:02:50,980
|
|
we need to add a comment to be added to the commit.
|
|
|
|
56
|
|
00:02:50,980 --> 00:02:54,760
|
|
So here we simply write in Added README file, then we
|
|
|
|
57
|
|
00:02:54,760 --> 00:02:58,170
|
|
can close and save And this will add the file to the
|
|
|
|
58
|
|
00:02:58,170 --> 00:03:01,310
|
|
Git repository. The local Git repository of course. At this
|
|
|
|
59
|
|
00:03:01,310 --> 00:03:04,220
|
|
point, if we ran Git status again to see where we are.
|
|
|
|
60
|
|
00:03:04,220 --> 00:03:06,400
|
|
You can see that Git tells you that there is nothing
|
|
|
|
61
|
|
00:03:06,400 --> 00:03:08,660
|
|
to commit. Because of course the only file that we have, is
|
|
|
|
62
|
|
00:03:08,660 --> 00:03:13,070
|
|
committed to the repository. Now, let's make some changes to our
|
|
|
|
63
|
|
00:03:13,070 --> 00:03:17,270
|
|
README file. I'm just going to add some text here. Once more, we
|
|
|
|
64
|
|
00:03:17,270 --> 00:03:20,050
|
|
can run git status, and at this point, git knows about
|
|
|
|
65
|
|
00:03:20,050 --> 00:03:23,430
|
|
this file. So, it will know that README file has been modified.
|
|
|
|
66
|
|
00:03:23,430 --> 00:03:25,280
|
|
Remember that before, it was telling you that it was a new
|
|
|
|
67
|
|
00:03:25,280 --> 00:03:28,310
|
|
file, now it knows that there was a different version in the
|
|
|
|
68
|
|
00:03:28,310 --> 00:03:31,430
|
|
repository. So something we can do, at this point, for example, is
|
|
|
|
69
|
|
00:03:31,430 --> 00:03:34,820
|
|
to check the differences. Between this file and the committed one by
|
|
|
|
70
|
|
00:03:34,820 --> 00:03:38,040
|
|
executing get diff readme and if you look at the output of
|
|
|
|
71
|
|
00:03:38,040 --> 00:03:42,320
|
|
the get diff command here, you can see that this line, readme
|
|
|
|
72
|
|
00:03:42,320 --> 00:03:45,170
|
|
file content was added and you'll see that it was added because
|
|
|
|
73
|
|
00:03:45,170 --> 00:03:48,610
|
|
there's a plus sign before that line. In case of deletion of lines,
|
|
|
|
74
|
|
00:03:48,610 --> 00:03:51,460
|
|
you'll see a minusm sign there. So at this point, if we
|
|
|
|
75
|
|
00:03:51,460 --> 00:03:54,950
|
|
want to commit our file, remember that we'll always have to tell git
|
|
|
|
76
|
|
00:03:54,950 --> 00:03:58,070
|
|
that we want to stage the file before committing it. Otherwise, it
|
|
|
|
77
|
|
00:03:58,070 --> 00:04:01,420
|
|
will be ignored by the commit operation. So to tell git, that the
|
|
|
|
78
|
|
00:04:01,420 --> 00:04:04,140
|
|
file has to be staged, we will, can use the usual git
|
|
|
|
79
|
|
00:04:04,140 --> 00:04:07,140
|
|
add command. But if you remember the lesson, we can also use a
|
|
|
|
80
|
|
00:04:07,140 --> 00:04:10,150
|
|
shortcut. So you, we don't really have to do this in two steps.
|
|
|
|
81
|
|
00:04:10,150 --> 00:04:13,730
|
|
We can simply say, git commit -a, and this will tell git to
|
|
|
|
82
|
|
00:04:13,730 --> 00:04:17,120
|
|
commit all of the files that git knows about, which in this
|
|
|
|
83
|
|
00:04:17,120 --> 00:04:19,959
|
|
case is only the written file of course. Something else that we can
|
|
|
|
84
|
|
00:04:19,959 --> 00:04:22,950
|
|
do, is that we can also provide the right away message for
|
|
|
|
85
|
|
00:04:22,950 --> 00:04:26,140
|
|
the commit, without having to open an editor. So, to do that we
|
|
|
|
86
|
|
00:04:26,140 --> 00:04:29,760
|
|
can specify the -n option. And at this point a we can
|
|
|
|
87
|
|
00:04:29,760 --> 00:04:34,050
|
|
just put a in double quotes our content we press enter and as
|
|
|
|
88
|
|
00:04:34,050 --> 00:04:36,690
|
|
you can see it will notify us that one file was changed
|
|
|
|
89
|
|
00:04:36,690 --> 00:04:38,850
|
|
and in particular it will also tell you that there was an a
|
|
|
|
90
|
|
00:04:38,850 --> 00:04:41,470
|
|
insertion again if we run git status you will see that
|
|
|
|
91
|
|
00:04:41,470 --> 00:04:44,800
|
|
there is nothing else to commit. So now lets imagine that
|
|
|
|
92
|
|
00:04:44,800 --> 00:04:48,390
|
|
you want to see the version history for your repository. You
|
|
|
|
93
|
|
00:04:48,390 --> 00:04:51,760
|
|
can do that by running the git log command. So if
|
|
|
|
94
|
|
00:04:51,760 --> 00:04:54,560
|
|
you run that, it will show you all the different commits
|
|
|
|
95
|
|
00:04:54,560 --> 00:04:57,990
|
|
For your repository. And each commit has got a commit ID, as
|
|
|
|
96
|
|
00:04:57,990 --> 00:05:01,010
|
|
you can see here and the one down here is
|
|
|
|
97
|
|
00:05:01,010 --> 00:05:04,740
|
|
the first commit, where as the one above is the second commit.
|
|
|
|
98
|
|
00:05:04,740 --> 00:05:07,670
|
|
And as you can see, we'll also show you the comments associated
|
|
|
|
99
|
|
00:05:07,670 --> 00:05:11,070
|
|
with each commit. And in case you wanted to see the changes introduced
|
|
|
|
100
|
|
00:05:11,070 --> 00:05:14,500
|
|
by a commit. You can use that git show command, and you
|
|
|
|
101
|
|
00:05:14,500 --> 00:05:18,220
|
|
can provide the commit ID for the commit that you're interested in.
|
|
|
|
102
|
|
00:05:18,220 --> 00:05:20,600
|
|
And you don't really need to provide the whole ID, you can
|
|
|
|
103
|
|
00:05:20,600 --> 00:05:23,600
|
|
provide the first four or more characters. So that's what we're going to
|
|
|
|
104
|
|
00:05:23,600 --> 00:05:26,540
|
|
do here. So we're going to specify the second commit, and when we
|
|
|
|
105
|
|
00:05:26,540 --> 00:05:31,120
|
|
execute the command it will show use the changes introduced by that commit.
|
|
|
|
106
|
|
00:05:31,120 --> 00:05:33,550
|
|
To fetch a repository from a remote server, you can
|
|
|
|
107
|
|
00:05:33,550 --> 00:05:36,350
|
|
use the git clone command. So you will write git clone
|
|
|
|
108
|
|
00:05:36,350 --> 00:05:39,140
|
|
and then specify the URL. For the remote repository. Here
|
|
|
|
109
|
|
00:05:39,140 --> 00:05:44,260
|
|
we are using the SSH protocal and there are different protocals
|
|
|
|
110
|
|
00:05:44,260 --> 00:05:46,680
|
|
that can be used, so the remote repository can be
|
|
|
|
111
|
|
00:05:46,680 --> 00:05:49,800
|
|
made available in different ways. As you can see, when you
|
|
|
|
112
|
|
00:05:49,800 --> 00:05:54,050
|
|
clone the project, the project is cloned into the local directory.
|
|
|
|
113
|
|
00:05:54,050 --> 00:05:57,180
|
|
If you wanted to import the project under a different name.
|
|
|
|
114
|
|
00:05:57,180 --> 00:05:59,790
|
|
You could just specify the name that you want for the
|
|
|
|
115
|
|
00:05:59,790 --> 00:06:03,110
|
|
Local Directory. For example, in this case, myproject2. And,
|
|
|
|
116
|
|
00:06:03,110 --> 00:06:06,630
|
|
so here you'll get the project in my local work space
|
|
|
|
117
|
|
00:06:06,630 --> 00:06:09,530
|
|
with the name that I specified. So, let's go inside one
|
|
|
|
118
|
|
00:06:09,530 --> 00:06:12,020
|
|
of these two projects that have the same content because they're
|
|
|
|
119
|
|
00:06:12,020 --> 00:06:14,930
|
|
coming from the repository. If you want to see the details
|
|
|
|
120
|
|
00:06:14,930 --> 00:06:18,550
|
|
of the server you can use the remote command and specify
|
|
|
|
121
|
|
00:06:18,550 --> 00:06:22,230
|
|
the flag -v. And here we'll show you what is the remote
|
|
|
|
122
|
|
00:06:22,230 --> 00:06:25,560
|
|
repository now let's go ahead to make some changes to the project
|
|
|
|
123
|
|
00:06:25,560 --> 00:06:28,820
|
|
for example let's add a file. So I'm just going to create this
|
|
|
|
124
|
|
00:06:28,820 --> 00:06:31,230
|
|
empty file which I am going to call new file I'm going to
|
|
|
|
125
|
|
00:06:31,230 --> 00:06:34,890
|
|
add it to my index so that it gets committed. Later on and
|
|
|
|
126
|
|
00:06:34,890 --> 00:06:37,650
|
|
then I'm going to run git commit to actually commit it to the
|
|
|
|
127
|
|
00:06:37,650 --> 00:06:41,570
|
|
local repository. And I'm going to specify the comment for the commit right
|
|
|
|
128
|
|
00:06:41,570 --> 00:06:44,120
|
|
away here from the command line. So when we do that the
|
|
|
|
129
|
|
00:06:44,120 --> 00:06:47,680
|
|
file gets added to my local repository. And if we want to double
|
|
|
|
130
|
|
00:06:47,680 --> 00:06:50,690
|
|
check that, we can run git log. And if you look at
|
|
|
|
131
|
|
00:06:50,690 --> 00:06:53,360
|
|
the last commit at the top, you can see that it's telling
|
|
|
|
132
|
|
00:06:53,360 --> 00:06:56,980
|
|
me that the new file was added to the repository, showing the
|
|
|
|
133
|
|
00:06:56,980 --> 00:06:59,940
|
|
comment that I added. But this is just for the local repository,
|
|
|
|
134
|
|
00:06:59,940 --> 00:07:03,100
|
|
so I need to use the git push command to push it
|
|
|
|
135
|
|
00:07:03,100 --> 00:07:06,250
|
|
to the remote repository. And at this point, when I run that,
|
|
|
|
136
|
|
00:07:06,250 --> 00:07:09,890
|
|
my local changes will be committed. To the remote repository. So now
|
|
|
|
137
|
|
00:07:09,890 --> 00:07:13,110
|
|
let's go to the other copy of the project that we created.
|
|
|
|
138
|
|
00:07:13,110 --> 00:07:16,660
|
|
The one under directory myproject2. If you remember this project was
|
|
|
|
139
|
|
00:07:16,660 --> 00:07:19,610
|
|
linked up to the same remote project. But of course, if we run
|
|
|
|
140
|
|
00:07:19,610 --> 00:07:22,720
|
|
get log here, we don't see this latest change that we made, because
|
|
|
|
141
|
|
00:07:22,720 --> 00:07:25,970
|
|
we didn't synchronize this local copy with the remote copy. And so we
|
|
|
|
142
|
|
00:07:25,970 --> 00:07:28,530
|
|
just have these files, the README and ,Five that worked there before.
|
|
|
|
143
|
|
00:07:28,530 --> 00:07:30,720
|
|
So what we need to do is that we need to pull the
|
|
|
|
144
|
|
00:07:30,720 --> 00:07:34,180
|
|
changes from the remote repository using git pull, and when we do that,
|
|
|
|
145
|
|
00:07:34,180 --> 00:07:38,130
|
|
that will actually pull these changes and therefore, create the new files that
|
|
|
|
146
|
|
00:07:38,130 --> 00:07:41,340
|
|
we created in the other directory. And if we run git log now,
|
|
|
|
147
|
|
00:07:41,340 --> 00:07:43,790
|
|
you can see that now we have the new entry. The comment at
|
|
|
|
148
|
|
00:07:43,790 --> 00:07:46,920
|
|
the top, that says this new file was added and of course, this
|
|
|
|
149
|
|
00:07:46,920 --> 00:07:49,880
|
|
is just an example, so we had two copies of the project on the
|
|
|
|
150
|
|
00:07:49,880 --> 00:07:52,990
|
|
same machine and for the same user, so the normal users scenario for
|
|
|
|
151
|
|
00:07:52,990 --> 00:07:56,230
|
|
this, it will be that, each user will have their local copy, but this
|
|
|
|
152
|
|
00:07:56,230 --> 00:07:59,220
|
|
should have given you the idea of how, git allows you to work
|
|
|
|
153
|
|
00:07:59,220 --> 00:08:03,210
|
|
on some local file. Commit them and push them to a remote repository and
|
|
|
|
154
|
|
00:08:03,210 --> 00:08:06,680
|
|
other users to get your changes, do further changes push
|
|
|
|
155
|
|
00:08:06,680 --> 00:08:08,860
|
|
them as well and then, you know, they will allow you
|
|
|
|
156
|
|
00:08:08,860 --> 00:08:10,890
|
|
to get their changes, and so on and so forth. So
|
|
|
|
157
|
|
00:08:10,890 --> 00:08:15,540
|
|
really allows this collaboration between different users and keeping track
|
|
|
|
158
|
|
00:08:15,540 --> 00:08:18,730
|
|
of all the changes made by the different users. So now
|
|
|
|
159
|
|
00:08:18,730 --> 00:08:21,860
|
|
let's look at some more advanced concept, which are the concept
|
|
|
|
160
|
|
00:08:21,860 --> 00:08:25,600
|
|
of branching, and merging. So what branching means is basically is
|
|
|
|
161
|
|
00:08:25,600 --> 00:08:28,540
|
|
to make a copy, to create a branch of the current
|
|
|
|
162
|
|
00:08:28,540 --> 00:08:32,070
|
|
project so that we can work on that copy indpendently from the
|
|
|
|
163
|
|
00:08:32,070 --> 00:08:34,740
|
|
other copy, from the other branch. And then we can decide whether
|
|
|
|
164
|
|
00:08:34,740 --> 00:08:37,190
|
|
we want to keep, both branches, or we want to merge them at
|
|
|
|
165
|
|
00:08:37,190 --> 00:08:40,510
|
|
some point. And you can of course have multiple branches, not just two.
|
|
|
|
166
|
|
00:08:40,510 --> 00:08:43,558
|
|
And the reason why this is particularly useful is because in many
|
|
|
|
167
|
|
00:08:43,558 --> 00:08:46,790
|
|
cases if you think, about the way we develop software in general,
|
|
|
|
168
|
|
00:08:46,790 --> 00:08:50,030
|
|
we work with artifacts. We might have the need to create kind
|
|
|
|
169
|
|
00:08:50,030 --> 00:08:53,910
|
|
of a separate copy of your work space. To do some experiments for example.
|
|
|
|
170
|
|
00:08:53,910 --> 00:08:54,940
|
|
So you want to change something in
|
|
|
|
171
|
|
00:08:54,940 --> 00:08:56,250
|
|
the code, you're not really sure it's going to
|
|
|
|
172
|
|
00:08:56,250 --> 00:08:57,650
|
|
work and you don't want to touch
|
|
|
|
173
|
|
00:08:57,650 --> 00:08:59,500
|
|
your main copy. So that's the perfect application
|
|
|
|
174
|
|
00:08:59,500 --> 00:09:00,830
|
|
for branching. If you want to do
|
|
|
|
175
|
|
00:09:00,830 --> 00:09:02,710
|
|
something like that...you want to experiment or do
|
|
|
|
176
|
|
00:09:02,710 --> 00:09:04,800
|
|
some modifications that you're not sure about,
|
|
|
|
177
|
|
00:09:04,800 --> 00:09:06,820
|
|
you will branch your code, you will do
|
|
|
|
178
|
|
00:09:06,820 --> 00:09:08,230
|
|
the changes...and then if you're happy with
|
|
|
|
179
|
|
00:09:08,230 --> 00:09:09,890
|
|
the changes, you will merge that branch
|
|
|
|
180
|
|
00:09:09,890 --> 00:09:13,250
|
|
with the original one, or worse if you're not happy with the changes you will
|
|
|
|
181
|
|
00:09:13,250 --> 00:09:16,680
|
|
just throw away that branch. So this is just one possible use of branch but
|
|
|
|
182
|
|
00:09:16,680 --> 00:09:18,950
|
|
it's one of the main uses of that. So in all let's see how that
|
|
|
|
183
|
|
00:09:18,950 --> 00:09:21,070
|
|
can be done with git. So first of all if you
|
|
|
|
184
|
|
00:09:21,070 --> 00:09:24,740
|
|
want to see which branches are currently present in your project, you can
|
|
|
|
185
|
|
00:09:24,740 --> 00:09:28,260
|
|
simply execute git branch, and in this case, you can see
|
|
|
|
186
|
|
00:09:28,260 --> 00:09:31,090
|
|
that there's only one branch, which is called master, and the star
|
|
|
|
187
|
|
00:09:31,090 --> 00:09:33,940
|
|
there indicates that this is our current branch. So how do
|
|
|
|
188
|
|
00:09:33,940 --> 00:09:37,210
|
|
we create a new branch? So we simply run the command
|
|
|
|
189
|
|
00:09:37,210 --> 00:09:41,010
|
|
git branch and specify a name for the new branch, for example we'll
|
|
|
|
190
|
|
00:09:41,010 --> 00:09:44,110
|
|
call it newBranch, to make it very explicit. At this point,
|
|
|
|
191
|
|
00:09:44,110 --> 00:09:46,940
|
|
if we run git branch of course, we will have
|
|
|
|
192
|
|
00:09:46,940 --> 00:09:50,410
|
|
a new branch plus master will still be our current branch. So
|
|
|
|
193
|
|
00:09:50,410 --> 00:09:52,780
|
|
if you want to switch to the new branch, we will use
|
|
|
|
194
|
|
00:09:52,780 --> 00:09:56,510
|
|
the git checkout command and specify the name of the branch that
|
|
|
|
195
|
|
00:09:56,510 --> 00:10:00,220
|
|
we want to become our current branch. So when we run that,
|
|
|
|
196
|
|
00:10:00,220 --> 00:10:02,780
|
|
git will tell us that we switched to the new branch. And
|
|
|
|
197
|
|
00:10:02,780 --> 00:10:05,920
|
|
if we run git branch you will see that now the star
|
|
|
|
198
|
|
00:10:05,920 --> 00:10:09,130
|
|
is next to newBranch because that's our current branch. There is a
|
|
|
|
199
|
|
00:10:09,130 --> 00:10:12,834
|
|
shortcut for these two commands. If you run the command git
|
|
|
|
200
|
|
00:10:12,834 --> 00:10:17,240
|
|
checkout specify the -b flag and then the name of
|
|
|
|
201
|
|
00:10:17,240 --> 00:10:19,790
|
|
the new branch it will do both things at the same
|
|
|
|
202
|
|
00:10:19,790 --> 00:10:22,910
|
|
time. It will create the new branch called testing in this
|
|
|
|
203
|
|
00:10:22,910 --> 00:10:25,760
|
|
case, and then it will switch to new branch and then
|
|
|
|
204
|
|
00:10:25,760 --> 00:10:28,860
|
|
it will tell you after executing the command. So now if
|
|
|
|
205
|
|
00:10:28,860 --> 00:10:31,290
|
|
we look at the git branch output, you can see that
|
|
|
|
206
|
|
00:10:31,290 --> 00:10:35,090
|
|
there is three branches and we are currently on the testing branch.
|
|
|
|
207
|
|
00:10:35,090 --> 00:10:37,300
|
|
So now let's create a new file and just call it test
|
|
|
|
208
|
|
00:10:37,300 --> 00:10:41,180
|
|
file, put some content in there, save it, we edit and commit it.
|
|
|
|
209
|
|
00:10:47,380 --> 00:10:50,280
|
|
And as you can see, now in this current branch, we have our
|
|
|
|
210
|
|
00:10:50,280 --> 00:10:53,430
|
|
testFile. So now let's switch to a different branch. So let's go back
|
|
|
|
211
|
|
00:10:53,430 --> 00:10:57,550
|
|
to the master branch using the usual git checkout command. So now if
|
|
|
|
212
|
|
00:10:57,550 --> 00:11:00,310
|
|
we do an ls, if we check the content of the current directory,
|
|
|
|
213
|
|
00:11:00,310 --> 00:11:03,140
|
|
we can see that the testFile is not there, because of course, it's
|
|
|
|
214
|
|
00:11:03,140 --> 00:11:06,070
|
|
not in this branch. so now let's assume that we are happy with
|
|
|
|
215
|
|
00:11:06,070 --> 00:11:09,260
|
|
the testFile that we created, with the modification that we made on the
|
|
|
|
216
|
|
00:11:09,260 --> 00:11:13,080
|
|
branch. And so we want to merge that branch with our master branch.
|
|
|
|
217
|
|
00:11:13,080 --> 00:11:16,180
|
|
To do that we can call the git merge command and
|
|
|
|
218
|
|
00:11:16,180 --> 00:11:19,260
|
|
we'll specify the branch that we want to merge with the current
|
|
|
|
219
|
|
00:11:19,260 --> 00:11:23,030
|
|
one. So we will specify testing in this case. That will merge
|
|
|
|
220
|
|
00:11:23,030 --> 00:11:26,260
|
|
the testing branch with the current branch, which is the master. Which
|
|
|
|
221
|
|
00:11:26,260 --> 00:11:29,200
|
|
means that now the testfile is in my current working directory,
|
|
|
|
222
|
|
00:11:29,200 --> 00:11:32,180
|
|
is in my current, Current branch. And if I run the branch,
|
|
|
|
223
|
|
00:11:32,180 --> 00:11:35,590
|
|
you'll see that the testing branch is obviously still there, so let's
|
|
|
|
224
|
|
00:11:35,590 --> 00:11:38,370
|
|
assume that we want to delete the testing branch at this point
|
|
|
|
225
|
|
00:11:38,370 --> 00:11:41,220
|
|
because we don't need it anymore. We could simply execute
|
|
|
|
226
|
|
00:11:41,220 --> 00:11:44,940
|
|
the branch -d which stands for -delete, specify
|
|
|
|
227
|
|
00:11:44,940 --> 00:11:47,670
|
|
the name of the branch and this will eliminate that
|
|
|
|
228
|
|
00:11:47,670 --> 00:11:51,670
|
|
branch as confirmed by running the command git branch or the
|
|
|
|
229
|
|
00:11:51,670 --> 00:11:55,030
|
|
testing branch no longer shows up. So, something that might
|
|
|
|
230
|
|
00:11:55,030 --> 00:11:57,200
|
|
happen when you merge a branch is, is that you
|
|
|
|
231
|
|
00:11:57,200 --> 00:12:00,000
|
|
might have conflicts For example, in case you change the,
|
|
|
|
232
|
|
00:12:00,000 --> 00:12:03,600
|
|
the same file into different branches. So, let's see an example
|
|
|
|
233
|
|
00:12:03,600 --> 00:12:06,730
|
|
of that. So, we're going to check which branches we have,
|
|
|
|
234
|
|
00:12:06,730 --> 00:12:09,260
|
|
so we have two branches, in this case, master and newBranch
|
|
|
|
235
|
|
00:12:09,260 --> 00:12:14,040
|
|
Our current branch is master. Let's open this file called new
|
|
|
|
236
|
|
00:12:14,040 --> 00:12:19,310
|
|
file and, add some content there. So now let's commit
|
|
|
|
237
|
|
00:12:19,310 --> 00:12:21,890
|
|
this changes to the get to the local repository. Now
|
|
|
|
238
|
|
00:12:21,890 --> 00:12:24,600
|
|
let's switch to the other branch and if you remember we
|
|
|
|
239
|
|
00:12:24,600 --> 00:12:26,900
|
|
do this by running git checkout and the name of the
|
|
|
|
240
|
|
00:12:26,900 --> 00:12:29,150
|
|
branch. And at this point we do the same operation here.
|
|
|
|
241
|
|
00:12:29,150 --> 00:12:32,090
|
|
So we take this file and we change it here to. In this
|
|
|
|
242
|
|
00:12:32,090 --> 00:12:34,740
|
|
case we have content that reflects the fact that we are. In the
|
|
|
|
243
|
|
00:12:34,740 --> 00:12:38,790
|
|
new branch just for convenience. At this point, we also can move the
|
|
|
|
244
|
|
00:12:38,790 --> 00:12:41,870
|
|
file here. The comment here is, of course, that this is the new
|
|
|
|
245
|
|
00:12:41,870 --> 00:12:44,800
|
|
file in the new branch. So, at this point, what we have here
|
|
|
|
246
|
|
00:12:44,800 --> 00:12:47,980
|
|
is that we have this file called newfile that has been modified
|
|
|
|
247
|
|
00:12:47,980 --> 00:12:51,320
|
|
independently both in the master branch and in the new branch. So we
|
|
|
|
248
|
|
00:12:51,320 --> 00:12:55,090
|
|
have a conflict. Right? So, now, let's switch back to the master branch.
|
|
|
|
249
|
|
00:12:55,090 --> 00:12:57,720
|
|
So now, let's say we want to merge the two branches. So
|
|
|
|
250
|
|
00:12:57,720 --> 00:13:00,490
|
|
since we are in master, we want to say that when I
|
|
|
|
251
|
|
00:13:00,490 --> 00:13:03,970
|
|
merge the new branch into the current one. And when we run
|
|
|
|
252
|
|
00:13:03,970 --> 00:13:07,540
|
|
that, we get an auto merging conflict. So at this point what
|
|
|
|
253
|
|
00:13:07,540 --> 00:13:10,390
|
|
we can do, is that we can manually fix the conflict by
|
|
|
|
254
|
|
00:13:10,390 --> 00:13:13,910
|
|
opening the new file. So the file that was showing the conflict.
|
|
|
|
255
|
|
00:13:13,910 --> 00:13:16,860
|
|
So here you can see the kind of of information that you get
|
|
|
|
256
|
|
00:13:16,860 --> 00:13:20,340
|
|
in the conflicted file. So it's telling you basically that there is
|
|
|
|
257
|
|
00:13:20,340 --> 00:13:23,760
|
|
in the head which is the, the master this conflict. Which is new
|
|
|
|
258
|
|
00:13:23,760 --> 00:13:26,830
|
|
file in master. Which is the content that we added of course. And
|
|
|
|
259
|
|
00:13:26,830 --> 00:13:30,190
|
|
then you know, under, you know, the separator you can see the content
|
|
|
|
260
|
|
00:13:30,190 --> 00:13:32,650
|
|
that was added in the new branch. Which is the contents in new
|
|
|
|
261
|
|
00:13:32,650 --> 00:13:35,990
|
|
file, in new branch. So basically, what this is showing you is the
|
|
|
|
262
|
|
00:13:35,990 --> 00:13:39,150
|
|
parts of the file that are conflicting. In this case, we only have
|
|
|
|
263
|
|
00:13:39,150 --> 00:13:41,990
|
|
one line, is basically the whole file into two versions and you can
|
|
|
|
264
|
|
00:13:41,990 --> 00:13:45,460
|
|
decide which version you want to keep or how you want to merge in
|
|
|
|
265
|
|
00:13:45,460 --> 00:13:48,260
|
|
general, the two pieces. So here, let's assume that we
|
|
|
|
266
|
|
00:13:48,260 --> 00:13:52,140
|
|
want to keep the content from the master. So what we're
|
|
|
|
267
|
|
00:13:52,140 --> 00:13:54,510
|
|
going to do is we're going to elimate the annotations
|
|
|
|
268
|
|
00:13:54,510 --> 00:13:57,500
|
|
and we're going to eliminate the additional content. We save this
|
|
|
|
269
|
|
00:13:57,500 --> 00:13:59,680
|
|
file. So at this point what we need to do
|
|
|
|
270
|
|
00:13:59,680 --> 00:14:04,040
|
|
is simply to commit the modified file (the merge file) and we
|
|
|
|
271
|
|
00:14:04,040 --> 00:14:07,440
|
|
do that in the normal way. We call git add, specifying
|
|
|
|
272
|
|
00:14:07,440 --> 00:14:11,180
|
|
the file, so git add newfile. Then we run git commit
|
|
|
|
273
|
|
00:14:11,180 --> 00:14:15,630
|
|
newfile, and we specify in the comment for clarity that this is the merged file,
|
|
|
|
274
|
|
00:14:15,630 --> 00:14:19,530
|
|
so that we performed a merge. And at this point we are done with our merge.
|