So we are able to save different snapshots,
different commits,
and by initializing a good repository,
these commits are all part of a so-called branch.
In our case here,
the default branch is the so-called master branch.
How can we see this?
Well, first by running "git status",
once again we know this command already.
There you'll see that we are on the branch master here.
And besides that,
we also have a command which lists all the branches inside
our Git project.
And this command is simply "git branch".
Git branch here doesn't show us well, too much information.
We have one branch only.
And currently we are in this branch.
This is indicated by the green color here
and by this asterisk ahead of the branch name.
As we saw it, when running Git in it,
we also have the ability to rename a branch.
Typically and historically,
the default branch inside a Git project was named "master".
In the last months and years, this changed.
Nowadays, we typically also use "main" instead of "master".
We can of course change the name,
we'll do this in a few seconds.
It's just important to keep in mind that this master
or main branch, typically is the branch
holding your main code, your working code.
For example,
the code you use for your currently running website,
for example.
If you want to implement new features,
you create new branches, work on that feature.
Once you're done,
you add these changes to the master branch.
We'll of course have a look at this flow in this lecture.
I just wanted to give you some insights already,
what is going to happen to get a better idea
of this branch concept immediately.
Let's get started by renaming this branch, tho.
Currently, we are inside the branch that we want to rename.
So the master branch in our case,
and if we now run "git branch -m",
and now add the new name
that we want to use for this branch,
in our case, this could be "main".
Well, by doing this, you get no confirmation at all,
but if you then run "git branch",
you'll see that "master" now changed to "main".
This didn't have any kind of impact on through commits
inside this branch.
It was just a plain renaming.
Now let's say that this content of this main branch here
is exactly what you want to have.
So you want to have this test or text file
and the second commit,
and now we want to add, well, additional data,
but not immediately into this main branch.
We first want to add this data, write some code,
test the code.
And then once it's done, we want to implement this code
into this main branch, into our main project, so to say.
What we need for this is a new branch.
And to create new branches in Git,
we have a, well, command obviously,
and this command is called "git checkout".
Checkout here simply means we refer to another branch.
Checkout can also be used to switch between branches.
In our case, not possible as we only have a single branch
only at the moment.
And now with " -b",
this simply means that we want to check out a new branch
and create a new branch based on the branch
we are currently in.
So based on our main branch here,
and now we can give this branch a name.
There is no strict naming convention here.
In my case, I'll simply call it "feature",
as this branch will add a new feature
to our main branch in the end.
With this command, you get the confirmation
that we switched to a new branch, named "feature"
and by running "git branch" now,
you'll see that we are already in this feature branch.
Again, indicated by the green color and that asterisk.
And if we check the commits inside this feature branch
with "git log",
well, you see no difference, right?
We are still having the same commits
that we had in the main branch,
and you also get the information up here that,
well basically,
this commit with this ID is the head.
The head is so to say the latest commit
of a specific branch.
So this commit is the head of both the feature
and the main branch.
With this now we can work on code as I said,
that we might want to implement in this feature branch.
Here I'll keep things simple again,
as this module is just about understanding
how Git generally works.
Therefore we could create a new folder and let's say,
"new feature", for example.
And in there, we simply add the "feature.txt" file.
So this is content that we now only have
in our feature branch.
So if you now run "git status" once again,
you see we are on the feature branch,
that's important, and we have untracked files.
So we basically have this new feature folder and all the
files it contains.
Therefore, we can now run again "git add . "
to add all newly added files
and changes made to tracked files.
And now we commit this change
with "git commit -m "added mew feature"".
Like this, the commit was successful.
If we check our log, once again,
you see we have three commits now in our feature branch,
but only two commits in our main branch.
You can again see this by this head.
So here, the latest commit is in the feature branch,
this one here.
Whereas the second commit,
so this one we created earlier,
is part of the main branch only.
And now the question is,
how can we bring these changes together?
How can we add this feature,
this commit added in the feature branch, to our main branch?
Well, for this, we first leave our log with Q once again,
and then we have to merge the two branches.
Merging branches simply means you combine
the two commits of these branches.
Well, to have a merged branch with all the code
implemented or incorporated in this branch.
Merging always works from a
"I am currently in a branch that should receive
additional commits", way of thinking.
So in our case,
this means that if we want to add the feature that we just
edit in the feature branch to our master branch,
we have to switch to the master branch first
and then merge the feature branch into the master branch.
To do that, we should check out our master branch therefore,
so "git checkout master",
which doesn't work as we renamed it to "main".
So, my bad here.
So we should of course refer to the main branch.
Here we are.
Now, you'll see in our git log that inside the main branch
we only have these two commits.
But, by now running "git merge",
and now referring to the branch that contains the commits
that should be merged into our main branch here,
so we run "git merge feature".
So the branch name of the other branch.
Well, if we do that, you see that now,
although we are still in the master branch,
we have this new feature folder
an alternate text file added into this branch.
And by again running "git log",
this, you see that now again,
both branches here main and feature are the so-called head,
so in simple words,
the latest commit of the branches,
and therefore this feature
is now available while also in this main branch.
So this was a successful merge,
but what happens if we accidentally work
on the same code section, on the same code snapshot
in the same file and then we try to run such a merge?
This would obviously lead to a conflict
because we have changes applied to the same well,
position so to say in our code,
and then we have to decide, well, which change wins.
So which change should be kept.
We are currently in the master branch,
therefore we could go to our "test.txt" file.
And we could say that we, don't call this.
This is my first commit.
But this is another commit here, right? Like this.
So we then add this and commit this change
with a message of "updated test.txt" .
So we did that.
And if we now check our log,
you see that we have well, a new commit in here,
updated test.txt in our main branch,
which doesn't affect the feature branch at the moment.
So we can leave the log again
and now check out the feature branch.
Let me clear this.
And here we still have the initial stage, right?
So the unchanged text.
And now we say, well,
"this is again a commit", just to have a difference here.
So we save this now.
We also add this change to the staging area.
We commit this change inside our feature branch,
maybe with "changed test.txt content"
to have a different message here.
So we commit this. No problem here.
If in a run, our git log once again,
we see that this is all right.
So feature branch has this latest commit we just added.
And if we now, again, check out our master branch,
and again, my bad, I'm sorry about this.
I typically work with "master" still,
therefore I'm not totally used to "main" here.
So "git checkout main".
Clear it.
Now we again, run our merge command.
So "git merge" and we merged a feature branch
into our main or master branch.
So "git merged feature".
Then we see that we have well emerged conflict
because we have a current change.
This is the change we have in our current branch.
So in our case,
the main branch, and we have an incoming change.
This is the change that we made in the feature branch.
So the branch that we want to merge into this master branch,
and therefore we have well,
multiple options to fix this merge conflict.
Visual studio code is a great help here, by the way.
And well basically,
the most common things we do is either compare the
changes over here, or we accept the current change.
So the change in our current branch or the incoming change.
So as I said, the change from the feature branch here.
If we accept that incoming change here, for example,
we can simply click right here
and then we see if we still have a warning.
So, if we save this now and run "git status",
you see we have unmerged paths because
that was the problem that we have.
But now with the accepted incoming change
and saving the file,
we need to create another commit.
So let's run "git add",
and let's now commit this change with a message of
"merged text.txt from feature", for example,
and with this, now clear this once again and run "git log".
You see that in here,
we now have the latest commit from the feature branch.
So this is now part of our main branch.
And additionally,
we have that merge commit.
So this is basically the commit that we just created
that brought these two branches together
without any conflicts as we just, well solved these.
So, this is it about creating commits
and creating branches and merging branches.
Now, the next question is, how can we actually delete data?
So delete commits, delete branches and so on.
This is how we will continue in the next lecture.