git for research basics: fundamentals, commits, branches, merging
git research commit merge conflict
Don't watch this if you already know how to solve a merge conflict :)
 Hi there. Today we're taking a look at Git, especially Git as it is used maybe in research collaborations. So Git is like a tool to collaborate, but when you research, like when you work on a paper together with other people, you won't use a lot of the features that Git offers and that are usually described by Git. So in this series I want to talk about what's kind of the most simple way to collaborate with people on a research project using Git. And today we're going to go over just the fundamentals, which makes everything else a lot easier. So what you need to understand about Git is that fundamentally Git is a graph, and it's a graph of commits. What I mean by this. So let's say you have your paper, you write some things, and then this is kind of version one. And then you have another paper, or the same paper, and you kind of change this line here. That's version two, and so on. You have kind of this chain of versions that you would like to keep in store. So this is the classic example of version control, where you would like to save these versions, and do it in a way that you can at any point in time go back to any version previously. And this is exactly what Git does, without you having to kind of rename. Like people usually copy the file and then rename like this version two, version three, final version, really final version, really final version corrected, blah blah blah. Alright, so Git fundamentally is a graph, and a graph of an object we call a commit. So a commit, which I'm going to represent as a bubble here, is simply a kind of an image of your hard drive, or one folder of your hard drive at a particular point in time. So this will contain all kind of files. Let's call this file A, file B. Oops, well, I meant to make a square here. But all the files that are in your folder, which is called the Git repository, or it's not correct, but bear with me. You have this folder, and all the files in this folder, when you make a commit, all these files are kind of saved as they are into one of these bubbles. And they're saved forever basically in this status that they are. So what you can do now is you can go ahead and make a second commit. So you change a bunch of files. Let's say the file B is still the same, but the file A has changed, is now A'. You make a second commit, and the second commit references the first commit. So part of a commit, except the very first commit, part of a commit is always a pointer to its parent commit. And especially if you look at the commits, they all have names. And the name of a commit is always its hash. And the hash includes basically the hash of all the files that are in there. So a hash could be something like F5C259, and so on. And for the next commit, the hash also includes the reference to the parent. That's why the integral part of a commit is to which parent it belongs. This ultimately is what makes the graph kind of the graph. Every commit references its parent. So you can address every commit by its name, as I said, which is the hash of the commit. So the hash is really long, but you can also simply reference it by the first couple of letters. As long as that's unique, Git will let you do this whenever you need to reference some commit. So we've discussed that basically a commit is a bunch of files, as they are, and it's saved in this state. So Git is of course smart. It will only save the diff from one to the other commit. But you can just imagine that a commit is simply the status of a folder at a particular point in time. So let me just take away these files here. There are a bunch of other things in Git. So one concept that Git has is called a tag. A tag is a name for a commit that you give yourself. And the tag is like a little flag that sticks in a commit. And you may say this, v1, version 1. This is simply a tag, and as you make new commits, the tag simply stays there. And at any time, if you don't want to remember this big long hash, you can simply refer to this commit as v1. Because that's the tag. It's kind of simple. The next form of a little flag that you can append to a commit is called a branch. And a branch, the difference between a tag and a branch. So a branch is also this flag, and we'll call it, I don't know, blah. The difference is that when you are on this commit here, right here, and you make a commit on top of this commit, while what's called you've checked out the blah branch. So right now you're looking at blah, which is this commit, and you make a commit on top of this commit. What Git will do automatically for you is it will erase this flag and move it to this next commit. So you might know branches from subversion or other version control technologies. It's very similar, but in Git, a branch is simply like a tag. It's simply a name for a commit. But with the additional property that when you make a commit on top of that commit, so when it has the commit as its parent, then Git will move the branch, the little flag, to the new commit. So basically, you always have that one branch, which is called master. Git creates this automatically for you if you just have this little flag, master. And you make a commit on top of master, which would cause master to go here. So people usually say they work on the master branch, which means they're simply making commits on top of the commit that currently has the master flag. Git also allows you to move around both tags and the branches basically to any commit. So I could forcefully go erase this here and simply stick the master flag here. And sometimes if we kind of decide these two commits are no good, we would simply do this. We would simply take the master flag, put it here, and then when we make a new commit on top of the master now, what we would make is we make a new commit point here, then Git would move the master flag because it's a branch, master, and then we simply continue working here, working here, and Git will happily move along this master. So in Git, there is no need to actually delete commits or something like this. What we can simply do is kind of move the branch that we're working on to the commit we like, and garbage collection ultimately will at some point go and delete these two commits. This is a bit more difficult once you collaborate with other people, because they might actually have made commits that reference the commits that you just kind of deleted or so. So it's a bit tricky, but ultimately this is something you can do. So the next thing we're going to talk about is multiple branches. Having multiple branches basically boils down to you have few commits, you have your graph, and let's say this is your master branch. So here we have master, but also, or let's make the one before, otherwise I don't have space, master. So what someone else would like to do is say, hey, I want to try out this new feature in code. It will probably change the code base and so on, but I want to try it out. Maybe it'll introduce some bugs and so on. And then what you can do is you can make a new branch, F1, let's call it F1 for feature one. And then I can make a commit on top of feature one, which would then move the feature one flag to here, and so on. I can make second and third commit and so on. Meanwhile, the other people working on the project, or maybe even you yourself, can work on top of this commit, on top of the master branch. So in kind of software engineering, this is typically used when one part of the team wants to implement a new feature, but the other part of the team kind of continues to do bug fixes or things like this, development on the version of the software that doesn't yet have the new feature. But they kind of need to fix bugs, and since the new feature is not complete yet, they can't both work on the same code base. So each work on their own branch, so to say. And at the end, when feature one is ready, people say, okay, we've implemented it, it's all good, there's no bugs. We would like to integrate the feature one into the main software, basically. What you have to do is you would have to do a so-called merge. A merge is a process that generates a merge commit, and a merge commit is this thing here. As you notice, it has more than one parent. It has, in this case, two parents where it kind of combines. So from this commit here, both branches are based off of this commit. And then changes were made, individual changes, in this branch and in this branch. So there's the possibility that people change different things. And what the merge commit needs to do somehow is to bring together these changes. So actually, both branches might have changed the same file, but in a different way. And now the question is how do we merge these different files? And that's kind of the last topic we'll go into today. How does Git do a merge? So when we talk about merging, Git has a bunch of built-in algorithms that it helps you with. Most of the time, merging is automatic. So if you have files here, A and B, and in one branch, A is changed, some here, and in one branch, B is changed. Git simply assumes, well, this one branch has changed A, the other one hasn't. So the changes mean something. I'll take them. So basically, whenever something has changed in one branch and not changed in the other, it will assume that the changes are the thing that needs to continue to live. It assumes that the changes were made for a reason, and that reason should continue. So one might be a bug fix, the other one might be the new feature. The same goes in the same file. So when you have the same file and in one branch something on top is changed, and the other branch something kind of on the bottom is changed, Git simply assumes both changes are wanted and takes both. The only kind of time when Git doesn't know what to do is when both branches change the same line. So I'm going to represent this with, I don't know, but when both branches change the same line in the same file, or close by, so there are these algorithms that Git determines when there's a so-called merge conflict. That's the only time where Git doesn't know what to do. And so as preliminary, it's a good idea to structure files in a line-based fashion, especially if you write kind of LaTeX. A good practice is to put every sentence on a new line and not have like giant lines of multiple sentences, because if you put every sentence on a new line, then you immediately kind of see where something was changed. Whereas if you have this big paragraph and Git will simply tell you this line has changed, which is an entire paragraph, and you don't see what's happening. So when you have a merge conflict, Git asks you what to do, and it does this in a very simple way. We're just going to kind of take a look here as a final demonstration. So I have a Git repository here. Let me do that. So as you can see, there's simply this test file in here. And I've just made one commit, the initial commit. And let's look at this test file. It simply says, hello. So what I can do is, for example, I can say, hi. When I want to make a new commit, first of all, Git status will always tell you kind of what you can do, what's happening in your Git repository. Here it says, changes not staged for commit, modified test.txt. And it also tells you what you can do. So it tells me, for example, use git checkout dash dash with the file name to discard changes. Or use git add to update what will be committed. There's a... I'll use git add with this. So it tells me changes to be committed. Now it's green, as you can see. So when I now type git commit, it should commit these changes. And this is a common occurrence in Git. Whenever you see a text editor opening, Git expects you to type a text message, like a commit message in this case, like a log message, basically. The hashtags are comments, which will not go in here. This is all described right here, actually, in these comments. The thing about these things is, when you type an empty message, then Git will abort the commit. Notice you've done something wrong, you can simply save this file with being empty, being nothing but comments, basically. Git will abort. So it's super useful. I'll just say, added hi, and then save this file. So this is not a special thing. All you need to do... This is an editor, a text editor, that edits a text file. You simply need to save the file and close the editor, and Git will be like, OK, cool, I'll continue. So with git log, now you can see we have two commits. We have my initial commit, and we have the commit called added hi. If you look at the test file, you see hi. So what we'll do now is, finally, we'll make two branches, as we've discussed before. So this is my initial commit. I've made one more commit. And we're on branch master right now, which Git status will tell you. See? On branch master. So this is now master. What we'll do is we'll make a new branch called F1. We'll make a commit on F1, meaning we'll move this. F1. Then we'll make a commit on top of master, like this, which means we'll move this. Master. And then we will merge F1 back into master, such that this master is here. And at the end, we can even remove the F1 branch. And we'll do this while we're having a merge conflict, so that you see the whole process. So, okay. So what I want to do is, first I want to make a branch F1. For this, we can use checkout minus B for making a new branch F1. If the branch already exists, you simply need to checkout, which means I simply go to where this branch is, to the commit that the branch references to. We also say we put head to this commit. Head is always the thing you're looking at, basically. The thing you've currently checked out. So, make a new branch F1, and we'll immediately switch to F1 if I type status. It says on branch F1. It's still the same commit, but we're just in a different branch. So we'll make kind of a change to this file here. I'm gonna say hello. Cool. Save the file. Status. It says it's modified. I want to add and commit it. And there's a shortcut. Commit minus A minus M. So the A simply says all the files that have changed, add them. So I don't need to add, git add all the changed files separately. Though this only counts for kind of changed files. If you have completely new files that git isn't tracking yet, you need to add them yourself. So here with a minus A, I skip the need to first add the files, and with the minus M I can give directly the commit message. More O. Cool. So now what we've done is we have made this commit here and moved the F1 flag to this commit. What we'll do now is we'll go back to this commit, which is currently master branch, and we'll make this commit. So first what we need to do is we'll go back to some commit, which is a checkout. Checkout master. Since master is still referring to that commit. As you can see, when I open the test file, there's no hello. It's the status from before. Hello. I can now change the file in some other manner. In this case I say hello, because I want many Es. And I can say I can commit this, because I'm now on the branch master. It will make this new commit here and move the master branch to that. More E. If you look at git log, you see all these commits on this kind of branch. You don't see the commit on the F1 branch. For that I would have to go back to the F1 branch. I log, and you see here it's a different story. After the added high commit, there's the more O commit. Whereas up here, after the added high commit, there's the more E commit. Merging also happens when you have different branches. When you collaborate with other people, and these people make commits, and you make commits independent of each other, and you try to synchronize your work, often you need to do a merge. And then merge conflicts can also happen. What we can do now is we can go back to master. Because we've... Oops. Git checkout master. There are shortcuts for all of these. We're on this branch right here. What we want to do is we want to make the merge commit. We want to merge F1 into master. While I am on master, I can say git merge F1. It will try to merge, but it will tell me conflict, automatic merge failed, fixed conflicts, and then commit the result. I can say git status. It will tell me you're currently merging. You have unmerged paths. And this test.txt file is both branches modified. I'll go into the test. This is very strange if you see it for the first time, but it's actually very intuitive. What git will do is wherever the line is that both branches have changed, or wherever the block of lines is that both branches have changed, git will basically indicate this by writing directly into the file. It will make these smaller, smaller, smaller, smaller, smaller than sign. Then it says head, which means this is the thing you're currently looking at, which we know is master, has changed this first line to this. Hello. Then it will be like equal, equal, equal, equal. Then it will say down here, it will say the F1 branch has changed this line, the same line to hello. It will denote the end of this with larger, larger, larger, larger, greater than signs. What you need to do in order to merge is simply make this file as you wish it is in the merged state. First of all, you can always start by removing, actually, good practice maybe to remove these equal lines. Then within these delimiters change how you want the file to look. In essence, I simply want to have these O's here at the end. I just want too many. Like this. Or like this. I like that. I'm going to call that the merged state. Then I delete these lines. This is the file that I would like the merged commit to have. What I can do is save this file. Again, I say git status. It still tells me it's unmerged, but it tells me what to do. It says use git add to mark resolution. I've resolved it. git add test txt. git status. It says all conflicts fixed, but you are still merging. Use git commit to conclude merge. git commit. Bam. I still have to enter a commit message, which is already predefined here. I'm saying I merged the branch F1 and there were conflicts, but that's fine. I like this message, so I'm simply going to save the file right here. When I look into git log, it now gives me the full story. First I have this added high commit, then I have the more O commit and the more E commit, which were in parallel to each other. Then I merged both branches into one. We're now right here. What I can do now is delete the F1 flag, because I don't need it anymore. I do that by git branch minus d F1. It says delete the branch F1. No commits are actually deleted when you delete the branch. It's simply the little flag that is deleted. The only danger is when you delete the little flag and the name, and you're unable to reach the commit from any other end. Here of course we have this master, and by following this edge here, we can reach this commit just fine. git won't delete it or garbage collect it. But git will also tell you when you're about to do something dangerous. So don't worry. With this I think you should already have many tools or many insights into git. In another video we're going to look at how to collaborate online with people, which isn't much harder than this. It's simply two more steps to push and pull your work from a server together with other people. Alright, so that was it. Take care.
 Hi there. Today we're taking a look at Git, especially Git as it is used maybe in research collaborations.
 So Git is like a tool to collaborate, but when you research, like when you work on a paper together with other people,
 you won't use a lot of the features that Git offers and that are usually described by Git.
 So in this series I want to talk about what's kind of the most simple way to collaborate with people on a research project using Git.
 And today we're going to go over just the fundamentals, which makes everything else a lot easier.
 So what you need to understand about Git is that fundamentally Git is a graph, and it's a graph of commits.
 What I mean by this. So let's say you have your paper, you write some things, and then this is kind of version one.
 And then you have another paper, or the same paper, and you kind of change this line here. That's version two, and so on.
 You have kind of this chain of versions that you would like to keep in store.
 So this is the classic example of version control, where you would like to save these versions,
 and do it in a way that you can at any point in time go back to any version previously.
 And this is exactly what Git does, without you having to kind of rename.
 Like people usually copy the file and then rename like this version two, version three, final version, really final version, really final version corrected, blah blah blah.
 Alright, so Git fundamentally is a graph, and a graph of an object we call a commit.
 So a commit, which I'm going to represent as a bubble here, is simply a kind of an image of your hard drive,
 or one folder of your hard drive at a particular point in time.
 So this will contain all kind of files. Let's call this file A, file B.
 Oops, well, I meant to make a square here. But all the files that are in your folder,
 which is called the Git repository, or it's not correct, but bear with me.
 You have this folder, and all the files in this folder, when you make a commit,
 all these files are kind of saved as they are into one of these bubbles.
 And they're saved forever basically in this status that they are.
 So what you can do now is you can go ahead and make a second commit.
 So you change a bunch of files. Let's say the file B is still the same, but the file A has changed, is now A'.
 You make a second commit, and the second commit references the first commit.
 So part of a commit, except the very first commit, part of a commit is always a pointer to its parent commit.
 And especially if you look at the commits, they all have names.
 And the name of a commit is always its hash.
 And the hash includes basically the hash of all the files that are in there.
 So a hash could be something like F5C259, and so on.
 And for the next commit, the hash also includes the reference to the parent.
 That's why the integral part of a commit is to which parent it belongs.
 This ultimately is what makes the graph kind of the graph.
 Every commit references its parent.
 So you can address every commit by its name, as I said, which is the hash of the commit.
 So the hash is really long, but you can also simply reference it by the first couple of letters.
 As long as that's unique, Git will let you do this whenever you need to reference some commit.
 So we've discussed that basically a commit is a bunch of files, as they are, and it's saved in this state.
 So Git is of course smart. It will only save the diff from one to the other commit.
 But you can just imagine that a commit is simply the status of a folder at a particular point in time.
 So let me just take away these files here.
 There are a bunch of other things in Git.
 So one concept that Git has is called a tag.
 A tag is a name for a commit that you give yourself.
 And the tag is like a little flag that sticks in a commit.
 And you may say this, v1, version 1.
 This is simply a tag, and as you make new commits, the tag simply stays there.
 And at any time, if you don't want to remember this big long hash, you can simply refer to this commit as v1.
 Because that's the tag. It's kind of simple.
 The next form of a little flag that you can append to a commit is called a branch.
 And a branch, the difference between a tag and a branch.
 So a branch is also this flag, and we'll call it, I don't know, blah.
 The difference is that when you are on this commit here, right here,
 and you make a commit on top of this commit,
 while what's called you've checked out the blah branch.
 So right now you're looking at blah, which is this commit, and you make a commit on top of this commit.
 What Git will do automatically for you is it will erase this flag and move it to this next commit.
 So you might know branches from subversion or other version control technologies.
 It's very similar, but in Git, a branch is simply like a tag.
 It's simply a name for a commit.
 But with the additional property that when you make a commit on top of that commit,
 so when it has the commit as its parent, then Git will move the branch, the little flag, to the new commit.
 So basically, you always have that one branch, which is called master.
 Git creates this automatically for you if you just have this little flag, master.
 And you make a commit on top of master, which would cause master to go here.
 So people usually say they work on the master branch,
 which means they're simply making commits on top of the commit that currently has the master flag.
 Git also allows you to move around both tags and the branches basically to any commit.
 So I could forcefully go erase this here and simply stick the master flag here.
 And sometimes if we kind of decide these two commits are no good, we would simply do this.
 We would simply take the master flag, put it here, and then when we make a new commit on top of the master now,
 what we would make is we make a new commit point here,
 then Git would move the master flag because it's a branch, master,
 and then we simply continue working here, working here, and Git will happily move along this master.
 So in Git, there is no need to actually delete commits or something like this.
 What we can simply do is kind of move the branch that we're working on to the commit we like,
 and garbage collection ultimately will at some point go and delete these two commits.
 This is a bit more difficult once you collaborate with other people,
 because they might actually have made commits that reference the commits that you just kind of deleted or so.
 So it's a bit tricky, but ultimately this is something you can do.
 So the next thing we're going to talk about is multiple branches.
 Having multiple branches basically boils down to you have few commits, you have your graph,
 and let's say this is your master branch.
 So here we have master, but also, or let's make the one before, otherwise I don't have space, master.
 So what someone else would like to do is say, hey, I want to try out this new feature in code.
 It will probably change the code base and so on, but I want to try it out.
 Maybe it'll introduce some bugs and so on.
 And then what you can do is you can make a new branch, F1, let's call it F1 for feature one.
 And then I can make a commit on top of feature one, which would then move the feature one flag to here, and so on.
 I can make second and third commit and so on.
 Meanwhile, the other people working on the project, or maybe even you yourself, can work on top of this commit,
 on top of the master branch.
 So in kind of software engineering, this is typically used when one part of the team wants to implement a new feature,
 but the other part of the team kind of continues to do bug fixes or things like this,
 development on the version of the software that doesn't yet have the new feature.
 But they kind of need to fix bugs, and since the new feature is not complete yet, they can't both work on the same code base.
 So each work on their own branch, so to say.
 And at the end, when feature one is ready, people say, okay, we've implemented it, it's all good, there's no bugs.
 We would like to integrate the feature one into the main software, basically.
 What you have to do is you would have to do a so-called merge.
 A merge is a process that generates a merge commit, and a merge commit is this thing here.
 As you notice, it has more than one parent.
 It has, in this case, two parents where it kind of combines.
 So from this commit here, both branches are based off of this commit.
 And then changes were made, individual changes, in this branch and in this branch.
 So there's the possibility that people change different things.
 And what the merge commit needs to do somehow is to bring together these changes.
 So actually, both branches might have changed the same file, but in a different way.
 And now the question is how do we merge these different files?
 And that's kind of the last topic we'll go into today.
 How does Git do a merge?
 So when we talk about merging, Git has a bunch of built-in algorithms that it helps you with.
 Most of the time, merging is automatic.
 So if you have files here, A and B, and in one branch, A is changed, some here, and in one branch, B is changed.
 Git simply assumes, well, this one branch has changed A, the other one hasn't.
 So the changes mean something. I'll take them.
 So basically, whenever something has changed in one branch and not changed in the other,
 it will assume that the changes are the thing that needs to continue to live.
 It assumes that the changes were made for a reason, and that reason should continue.
 So one might be a bug fix, the other one might be the new feature.
 The same goes in the same file.
 So when you have the same file and in one branch something on top is changed,
 and the other branch something kind of on the bottom is changed,
 Git simply assumes both changes are wanted and takes both.
 The only kind of time when Git doesn't know what to do is when both branches change the same line.
 So I'm going to represent this with, I don't know, but when both branches change the same line in the same file,
 or close by, so there are these algorithms that Git determines when there's a so-called merge conflict.
 That's the only time where Git doesn't know what to do.
 And so as preliminary, it's a good idea to structure files in a line-based fashion,
 especially if you write kind of LaTeX.
 A good practice is to put every sentence on a new line and not have like giant lines of multiple sentences,
 because if you put every sentence on a new line, then you immediately kind of see where something was changed.
 Whereas if you have this big paragraph and Git will simply tell you this line has changed,
 which is an entire paragraph, and you don't see what's happening.
 So when you have a merge conflict, Git asks you what to do, and it does this in a very simple way.
 We're just going to kind of take a look here as a final demonstration.
 So I have a Git repository here.
 Let me do that.
 So as you can see, there's simply this test file in here.
 And I've just made one commit, the initial commit.
 And let's look at this test file.
 It simply says, hello.
 So what I can do is, for example, I can say, hi.
 When I want to make a new commit, first of all, Git status will always tell you kind of what you can do,
 what's happening in your Git repository.
 Here it says, changes not staged for commit, modified test.txt.
 And it also tells you what you can do.
 So it tells me, for example, use git checkout dash dash with the file name to discard changes.
 Or use git add to update what will be committed.
 There's a...
 I'll use git add with this.
 So it tells me changes to be committed.
 Now it's green, as you can see.
 So when I now type git commit, it should commit these changes.
 And this is a common occurrence in Git.
 Whenever you see a text editor opening, Git expects you to type a text message,
 like a commit message in this case, like a log message, basically.
 The hashtags are comments, which will not go in here.
 This is all described right here, actually, in these comments.
 The thing about these things is, when you type an empty message, then Git will abort the commit.
 Notice you've done something wrong, you can simply save this file with being empty,
 being nothing but comments, basically.
 Git will abort. So it's super useful.
 I'll just say, added hi, and then save this file.
 So this is not a special thing. All you need to do...
 This is an editor, a text editor, that edits a text file.
 You simply need to save the file and close the editor, and Git will be like,
 OK, cool, I'll continue.
 So with git log, now you can see we have two commits.
 We have my initial commit, and we have the commit called added hi.
 If you look at the test file, you see hi.
 So what we'll do now is, finally, we'll make two branches, as we've discussed before.
 So this is my initial commit. I've made one more commit.
 And we're on branch master right now, which Git status will tell you.
 See? On branch master. So this is now master.
 What we'll do is we'll make a new branch called F1.
 We'll make a commit on F1, meaning we'll move this. F1.
 Then we'll make a commit on top of master, like this, which means we'll move this.
 Master. And then we will merge F1 back into master, such that this master is here.
 And at the end, we can even remove the F1 branch.
 And we'll do this while we're having a merge conflict, so that you see the whole process.
 So, okay. So what I want to do is, first I want to make a branch F1.
 For this, we can use checkout minus B for making a new branch F1.
 If the branch already exists, you simply need to checkout, which means I simply go to where this branch is,
 to the commit that the branch references to.
 We also say we put head to this commit.
 Head is always the thing you're looking at, basically. The thing you've currently checked out.
 So, make a new branch F1, and we'll immediately switch to F1 if I type status.
 It says on branch F1. It's still the same commit, but we're just in a different branch.
 So we'll make kind of a change to this file here. I'm gonna say hello.
 Cool. Save the file. Status. It says it's modified. I want to add and commit it.
 And there's a shortcut. Commit minus A minus M.
 So the A simply says all the files that have changed, add them.
 So I don't need to add, git add all the changed files separately.
 Though this only counts for kind of changed files.
 If you have completely new files that git isn't tracking yet, you need to add them yourself.
 So here with a minus A, I skip the need to first add the files,
 and with the minus M I can give directly the commit message. More O. Cool.
 So now what we've done is we have made this commit here and moved the F1 flag to this commit.
 What we'll do now is we'll go back to this commit, which is currently master branch, and we'll make this commit.
 So first what we need to do is we'll go back to some commit, which is a checkout.
 Checkout master. Since master is still referring to that commit.
 As you can see, when I open the test file, there's no hello. It's the status from before. Hello.
 I can now change the file in some other manner. In this case I say hello, because I want many Es.
 And I can say I can commit this, because I'm now on the branch master.
 It will make this new commit here and move the master branch to that. More E.
 If you look at git log, you see all these commits on this kind of branch.
 You don't see the commit on the F1 branch. For that I would have to go back to the F1 branch.
 I log, and you see here it's a different story. After the added high commit, there's the more O commit.
 Whereas up here, after the added high commit, there's the more E commit.
 Merging also happens when you have different branches.
 When you collaborate with other people, and these people make commits, and you make commits independent of each other,
 and you try to synchronize your work, often you need to do a merge.
 And then merge conflicts can also happen.
 What we can do now is we can go back to master.
 Because we've... Oops. Git checkout master.
 There are shortcuts for all of these.
 We're on this branch right here.
 What we want to do is we want to make the merge commit.
 We want to merge F1 into master. While I am on master, I can say git merge F1.
 It will try to merge, but it will tell me conflict, automatic merge failed, fixed conflicts, and then commit the result.
 I can say git status.
 It will tell me you're currently merging. You have unmerged paths.
 And this test.txt file is both branches modified.
 I'll go into the test.
 This is very strange if you see it for the first time, but it's actually very intuitive.
 What git will do is wherever the line is that both branches have changed,
 or wherever the block of lines is that both branches have changed,
 git will basically indicate this by writing directly into the file.
 It will make these smaller, smaller, smaller, smaller, smaller than sign.
 Then it says head, which means this is the thing you're currently looking at,
 which we know is master, has changed this first line to this.
 Hello. Then it will be like equal, equal, equal, equal.
 Then it will say down here, it will say the F1 branch has changed this line,
 the same line to hello.
 It will denote the end of this with larger, larger, larger, larger, greater than signs.
 What you need to do in order to merge is simply make this file as you wish it is in the merged state.
 First of all, you can always start by removing, actually, good practice maybe to remove these equal lines.
 Then within these delimiters change how you want the file to look.
 In essence, I simply want to have these O's here at the end.
 I just want too many. Like this.
 Or like this. I like that. I'm going to call that the merged state.
 Then I delete these lines. This is the file that I would like the merged commit to have.
 What I can do is save this file.
 Again, I say git status. It still tells me it's unmerged, but it tells me what to do.
 It says use git add to mark resolution.
 I've resolved it. git add test txt. git status.
 It says all conflicts fixed, but you are still merging. Use git commit to conclude merge.
 git commit. Bam.
 I still have to enter a commit message, which is already predefined here.
 I'm saying I merged the branch F1 and there were conflicts, but that's fine.
 I like this message, so I'm simply going to save the file right here.
 When I look into git log, it now gives me the full story.
 First I have this added high commit, then I have the more O commit and the more E commit,
 which were in parallel to each other.
 Then I merged both branches into one. We're now right here.
 What I can do now is delete the F1 flag, because I don't need it anymore.
 I do that by git branch minus d F1.
 It says delete the branch F1. No commits are actually deleted when you delete the branch.
 It's simply the little flag that is deleted.
 The only danger is when you delete the little flag and the name,
 and you're unable to reach the commit from any other end.
 Here of course we have this master, and by following this edge here, we can reach this commit just fine.
 git won't delete it or garbage collect it.
 But git will also tell you when you're about to do something dangerous.
 So don't worry.
 With this I think you should already have many tools or many insights into git.
 In another video we're going to look at how to collaborate online with people,
 which isn't much harder than this.
 It's simply two more steps to push and pull your work from a server together with other people.
 Alright, so that was it. Take care.