git for research basics: fundamentals, commits, branches, merging

hi there today we're taking a look at get in especially get as it is used maybe in research collaborations so it is like a tool to collaborate but when we do research like when you work on a paper together with other people you won't use a lot of the features that get offers and that are usually described by git so in this series I want to talk about how was kind of the most simple way to collaborate with people on like a research project using it and today we're gonna go over just the fundamentals and which makes everything else a lot easier so what do 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 1 and then you have another paper or the same paper and you kind of changed this line here that's version 2 and so on you have kind of this chain of versions that you would like to keep in store this so this is that 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 2 version 3 final version really final version corrected bubble all right so get fundamentally is a graph and a graph of an object we call a commit so 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 at a particular point in time so this will contain all kind of files let's call this file a file the oops well meant to make a square here but all the files in your folder which is the call to 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 there 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 and but the file a has changed is not a prime you make a second commit and the second commit references the first commit so part of a commit except the very first 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 f5c two five nine and so on and for the next commit the hash also includes the reference to the parent that's why that the integral part of a commit is to which parent it belongs this ultimately is what makes the graph kind of the graph I recommend and her references it's parent so you can address every commit by its name as I said which is the hash of the commit and you can also so the hash is like really long but you can also simply reference it by kind of the first couple of letters as long as that's unique it will let you do this whenever you need to reference some commit all right so we've discussed that basically a commit is a bunch of files as they are and it saved in this state so gates of course smart it will only kind of save the diff from one to the other but um you can just imagine that a commit to simply want the status of a formal rather particular point in time so let me just take away these files here there are a bunch of other things in git so the kind of um one concept that gate has is called the

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 V one version one this is simply a tag and as you make new commits and so on the tag simply states earned 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 that's kind of simple the next form of a little flag that you can append to commit is called a branch and a branch the difference between the tag and a branch so branches also is 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 bla branch so right now you're looking at blah which is this commit and you make a commit on top of this commit what kit will do automatically for you is it'll erase this flag and move it to this next commit bla so this is kind of so you might know branch is kind of from subversion or other version control technologies it's very similar but in get 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 that is its parent then it will move the branch the little flag to the new commit so basically you always have that one branch which is called master it creates this automatically for you if you just have this is a little flag master right and you make it commit on top of master which would cause master to go here master and so on 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 it also allows you to move around both tags and these little the branches basically to any comment so I could forcefully go erase this here and gently 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 we when we make it new commit on top of the master now what we would make is we make a new commit point here then it would move the master flag because it's a branch master and then we simply continue working here and get will happily move along this master so in get there is no need to actually delete commits or something like this what we can simply do is um 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 that'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 falls down to you have Fuca minutes 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 like is say hey I want to like try out this new feature in code it will probably change the code base and so on but I'm going 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 F one that's called f1 for feature one so and then you can I can make a commit on top of feature one which will 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 of 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 and 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 the feature one kind of is ready that people say like ok 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 know this is has more than one parent it has in this case two parents where the kind of combines so from this commits 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 you know 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're going to today how does get to a merge so when you talk about merging gift has a bunch of built-in algorithms that it helps you with most of the time merging is automatic so if you have like files here a and B and one in one branch a is changed some here and in one branch B has changed it simply as soon as well this one branch has changed a the other one hasn't so the changes you know they mean something I'll take them and as well and B so get basically whenever something has changed in one branch and not changed in the other it will assume that changes or the thing that needs to continue to live basically it assumes that the changes were made for a reason and that reason should you know continue so one might be a bug fix the other one might be the new feature this same goes in the same file so when you have the same file and one branch in one branch something on top is changed and the other branch something kind of on the bottom has changed it 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 represent this with I don't know but when both branches change the same line in the same file kind of or close by so there are these algorithms that keep determines when there's a so called merge conflict that's the only time work it 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 latte a good practice is to put every sentence on a new line and not have like giant lines of you know 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 it 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 it asks you what to do and it does this in a very simple way we're just gonna kind of take a look here as a final demonstration so I have a git repository here let me that so as you can see there's simply this test a file in here and I've just made one commit to 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 I can when I want to make a new commit first of all get status will always tell you kind of what you can do what's happening in your posit Ori here it says change is not staged for commit modified test dot txt and it also tells you what you can do so it tells me for example use get checkout - with the filename to discard changes or use get add to update what will be committed there's a I'll use get 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 common occurrence and yet whenever you see a text editor opening it expects you to type a text message like a commit message in this case that it like a log message basically um that 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 it when you type an empty message then gate will abort to commit so it's if you notice you've done something wrong you can simply save this file with them being empty being nothing but commit comments basically gate 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 get will be like okay cool I'll continue so with git log now you can see we have two comments we have my initial commit and we have to 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 I as we discussed before so this is my initial commit I've made one more commit and we're on branch master right now which get status will tell you 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 with which meaning we'll move this master and then we will merge f1 back into master such that kind of this master is here and at the end we can even kind of 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 check out - B for making

a new branch f1 if the branch already exists you simply need to check out which means I simply go to where this branch is - the commit that the branch references to we also say we put head where to D 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 will 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 - a - M so the ape simply says all the files that have changed I had 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 get isn't tracking yet you need to add them yourself but so here with a - a I skip the need to first add the vows and with the - em I can give directly the commit message more oh cool so now what we've done is where we have made this commit here and move to 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 check out 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 say I cannot change the file in some other manner in this case I say hello because I want many E's 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 II if you look at git log you see all these commits on this kind of branch you don't see the commits on the f1 branch for that I wouldn't have to go back f2 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 that at high commit there's the more e commit so merging and by the way merging also is not only happens when you have different branches but also because it's the same thing when you collaborate with other people and these people make commits and you make commits independent of each other and you kind of try to synchronize your work often you need to do a merge and then emerge conflicts can also

happen so what we do now is we come back to master because we yeah check out master they're like shortcuts for all of these but so we're on this branch right here and we want it what we're going to do is we want to make the merge commit and so we want to merge f1 into master so while I am on master I can say git merge f1 and it will try to merge but it will tell me conflict automatic merge failed fix conflicts and then commit the result I can say git status and it will tell me you're currently merging you have unmerged paths and this test or txt file is both branches modified it so I'm going to the test and this is very strange if you see for the first time but it's actually very intuitive so what it will do is wherever the line is that both branches have changed or whatever that the block of lines is that both branches have changed it will basically indicate this with by writing directly into the file so it'll make these smaller smaller smaller than sign and then it says head which means this is the thing you're currently looking at which we know it's master has changed this first line to this helo then it will be like equal equal and then it will say down here we'll say the f1 branch has changed this line the same line to hell and it will able to notice with like the end of this with like bit larger larger greater than signs so what you need to do to in order to emerge is simply you need to make this file as you wish it is in the merged State first of all you can always start by kind of removing actually a good practice may be to remove these equal lines and then within this delimiter is kind of change what you how you want the file to look in essence I simply want to have these OHS here at the end there's one too many like this or like this I like that so I'm gonna call that the murse and then I delete these lines so this is the file that I would like the two the merged commit to have so what I can do I 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 all right I've resolved it git add test. txt git status and it says all conflicts fixed but you are still merging use git

commit to conclude merge all right get commit damn and I'm still have to enter a commit message which is already predefined here saying I merged the branch f1 and there's conflict there were conflicts but that's fine I like this message so I'm simply gonna save the file right here and when I'm looking to get log it now gives me the full story first I have this added high commit then I have the more committed the more II committed which were in parallel to each other and then I merged both branches into one so we're now right here what I can do now is I can even delete the f1 flag because I don't need it anymore basically which I do by gate Brown - the f1 and it has deleted branch f1 so no commits are actually deleted when you delete the branch it's it simply the little flag is deleted the only danger is when you delete the little flat and the name and you're unable to reach the commit from any other name but here of course we have this master and by following this edge here we can reach this commit just fine so get won't delete it all right or garbage collected but it will also tell you when you're about to do something dangerous so don't worry all right so with this I think you should already have many tools or many insights into get and another video we're going to look at how to collaborate online with people which isn't much harder than this it's simply like two more steps to do to push and pull your work from a server together with other people alright so that was it take care