Kimberly Tran: Visualizing the Git Commit Graph

yeah hello everyone so my name is kim tran or kimberly tran um and i've been working with kids for like a long time now i think i first ran into git back in 2007 or so and i've worked with git in several organizations i introduce people to git so i'm kind of familiar with the difficulties that some that newer teams may have with adoption kit so this is um you know my attempt at a sort of gui tutorial that is not like most tutorial you see out there um so this tutorial or this international kit is is around the idea of approaching git at its most native which is a graph first approach so git is best understood as a system for manipulating graphs so what does your graph look like and then what do you want your graph to morph into what do you want your graph to look like and then what are the commands you should apply to get between those two graphs so that's why i'm calling this so the graph first approach you approach git not from the command basis or the state of your code but from the native elements of git itself which which are the the commits okay um so i have like 25 slides so i'm going to try to go through them fairly quick but also pause at certain slides um just for just for questions so the general outline of this presentation is we're going to go through the some basic gif fundamentals such as the sage and then i'll start throwing graphs at you all and show common use cases and how those graphs should be be morphed so you're going to see a lot of graphs in this in this presentation okay um so the typical introduction to git is is from is for a team that comes from a traditional non-distributed version control system so these are the systems that i can recollect uh working with um in my career so performance clearcase cvs feature source safe um and they're all very different from git they're they're not um they're not a distributed system they're central repository and so the terminologies and the way they work fundamentally is different also these systems don't have a clear model of how they work for instance when we were using cvs we actually had the consensus smartest guy in the room typical mit dropout who was the cvs maintainer every once in a while cvgs would messed up and then he would go into the cvs repository the database itself make some like weird commands and then straighten it things out and no one knew our cvs actually work gear is not like that gif has a really nice clean model how it works um and you can manipulate it using that model 100 reliably understand the model you understand git okay yeah so usually you come from these traditional systems you have you're interested to get commands and you try to map give commands to judicial version control systems that doesn't work very well because git has its own notion own models that if that is um that is inherent to its structure and doesn't map very well to to uh to traditional version control systems and it's compound and the problem is compounded by the fact that the commands and git may look the same for instance you have a checkout and a commit but they do very different things in git and that's one of the sources of difficulty so the usually confusion arises and people just don't know what gets into their code okay so we're going to start out with the fundamentals of git so these are the basic elements of git and the foundation we get git consists of commits which is the commit graph that we're going to talk about it's a database for your source code and then there's the working directory the index and the staging area the mysterious index or staging area which you'll see in the good documentation and then what i'm calling metadata which is branches tags and remotes it's data about the repository itself okay so it's very interesting that branches tags and remotes are actually metadata i don't consider those things like intrinsic to the git model they're actually an overlay onto commits working area and the index staging area okay and that part of it will be very key once once we'll talk more about what these this metadata does okay so i'm going to go through these one by one so it commits so get the database your code and just instantly the database is in that hidden git directory in your repo root okay um the smallest unit of change is a commit and you can think of commit then it's like a transaction in a regular database where the transaction or you're changed to your code base so here's an example of three changes over time the arrow of time in this presentation always goes from left to right and the commits are laid down and ordered you have your first commit a and then sometimes late you make another commit b that's based on a and then later on you create c i think you've all seen this type of graph before okay and though this is the model of how git represents commits it's also a very good working model in the sense that the state of your code any commit is determined by replaying all the commits that came before it so to get your code at c you traverse the graph finding all of a b and whatever and then you replay them one by one and that's almost exactly how git works in terms of like getting your working directory to some commit state now it has a ton of like um caching and fancy programs to make it like lighting speed but essentially that's how it works you always start from like the very first set of primordial commits then you replay the commit graph until you get to some some commit okay any questions about committee that i can take real quickly based on this understanding of what a commit is okay so i'm going to just keep on going through these these slides okay so next up is the commit graph so we already saw this simple commit graph of a b and c but there's also more complex commit graphs where be could have two parents so a commit always has some parents one or more parents except for their very first commits which don't have any parents so this is you've seen her also heard the term directed acyclic graph and what that means is that this graph there are no cycles in this graph so you can traverse from c and you may see a node more than once because uh it's a graph but you'll never get back to c itself so from c you can always get a deterministic set of nodes that were used to get to see itself okay and commits have a unique unique guarantees and are tampered proof in the sense that each of these commits has a hash and then that hash is actually um propagated to the hash of the new commit it's it's part of it of the new commit so that it's tamper proofs every commit is unique and you cannot tamper with that commit hash with the other people detecting it okay so they're like goods in that respect um and that's very powerful in the sense of you know if you want to pass commits around you can just refer to their commit hash and every single commitment in the world across every repository in the world is unique okay so you have commit graphs which is the database of your code but you can't work with that code until it's expressed in some of write in some sort of writable format and that's your working directory so the working directory is the edible state of your code it's as always relative to some commit it's just the file system so the file system mirrors the state of your commit and then it also it's also relative to an optional branch so that's actually key there because your working directory is usually is almost always it's always attached to commit but it because the branch is optional sometimes you may be off in what is known as the you might have seen already detach head state which means that you're on a commit that has no branch so you can work on it it behaves just like working on a branch except you can't refer back to that branch again via branch tag so the idea here is that it's the commit that is important and the branch being metadata is not so important that that's what i wanted to get across here okay so orient yourself to the commit and not necessarily the branch you have to be aware of the branch but just be aware that that branch is metadata okay um all right so now we get to the index staging area so we have like your commit graph which is like the current state a b and c now we want to make a change to this commit graph so anytime you make a change there's going to be a commit to b right so this d prime is the commit to be and that's exactly what the staging era is it's the commit that git is billing as you are working with your code it's a commit to be and changes have to be explicitly added to d from the working directory that's why you have the git add separation from the commit right you can actually do a commit and you can add anything the d prime the staging area the capacity b is empty and you get nothing right so um they cause the index staging area but i like to think of it as the commit to be the only difference between d prime and d itself once it's committed is that it becomes unmodifiable it gets locks in stone once you commit the changes and this is actually why git commit is a constant time operation and you can actually test it out yourself by just say like you know cloning the linux source repository leading to deleting the git repo and then re-adding everything and then you can find that git commit happens instantaneously no matter how many files you have because all it's doing there's commit that's already built and all it's doing is flipping a bit to make that a commit that's no longer edible so that's the staging area okay any questions about the staging area i know that can be a foreign concept to a lot of people because it's not a concept that's in other sorts of control systems okay i'll keep going okay so we get to the last bit of good fundamentals which is the metadata so git is you hear that git is append only and that's not entirely true because only the commit graph is append only you could add to the graph but you can't modify the existing graph and change the the links between two existing commits right it's not allowed you can only add this commit graph but everything else is fair game the tags the branches uh general bookkeeping like things like remotes and what branches mapped to what branches and it's all just metadata and furthermore that data metadata is actually contained in a text file within the dot git repo it's a config file you can actually look in there if you do things like adding a branch you can you'll look at that file and you'll see that a new entry has been added to that file so that git can know uh what branch is is tracking what which commit basically or which branches is tracking some remote uh commit for you to push and pull easily okay so that's a kind of a key concept that yes get us a pen only but only for commit graphs and what you're manipulating really is the metadata around what these branches and tags point to okay so that's just a quick just very fast overview of different fundamentals but i also hope that that's all you need to actually work with git is to understand that's the essenti the essential gift model and everything else is just synthetic sugar or or commands as you get to make it easier to work with mostly because commits nobody you can't remember commit hashes right humans have to attach like symbolic labels tsukumatash's allow them to work so almost all of git a lot of git is around this metadata system to keeping track of which branches point where okay okay so uh some more notes on the append pen only since the graph can only be added to this implies that it's the metadata is changing so furthermore that implies that a push for instance you do a good push what you're doing is changing what commit the branch is pointing at you're not changing the graph itself you're changing the branch there's a symbolic tag out there there's a symbolic slot for this branch and it has a pointers they commit and you're pointing it to some new commit so when you push the ultimate is always still there because it gives a pen only so if you know if you you know the commit hash it's numeric hash you can always get back to it so this leads to what i'm calling the push rule so when you push a branch the branch can only be pushed if no commits are lost and what that means is if you modify the branch you point to new commit that new branch you must be able to access the old commit from the new branch if you can't then that commit is lost right so that's sometimes when you push you'll see it will refuse to push because doing so would cause essentially data loss commits will not only be reachable okay so that's a sort of a key idea behind this presentation this this push rule okay questions okay let me assume no we'll go on to the the push rule in action so there are a number of uh cases so there's three cases the the push rule you can accept um reject or force so this is the accept case okay so this is the state of the remote repository abc here is a newly pushed commit d and you want origin developed point to d without losing data you can can you do this yes because when you do this c is still accessible so therefore the committee is accepted so the graph you can so by the push rule the the branches can move to a new commitment hash um deterministically deterministically without losing data meaning the old branch is still reachable the old commit is still reachable from the new commit okay so this is the normal happy past when you push something to the to the foreign repository so the other case is the reject case this is a more complex diagram okay so here is the remote repository so basically you would be someone else push c and you put push b b and d okay so when you try to push this and you want this shape here you want your shape to take precedent right you want to push this up there if you do it and set origin develop to d c is lost because it's no longer traversable from d itself you can go to b b and b and a but you can't just see these these are directed graphs there's no there's no pointer from b to c at all so you can't reverse this so therefore this is rejected and that's why when you push something like this git will say you have to it's it's uh the the foreign has changed and it rejects your new commit okay another key idea is that this push rule applies to every single branch there's nothing there's nothing special about the master or the develop branch it applies to branch that you create even so you have a private branch and it gets in this state perhaps because if you've done like rewrite your branches locally and you try to push you'll also get this newly pushed commit is rejected so it's a generic mechanism there's nothing special with those other branches okay so the last case is the force so this is like this exact previous same previous diagram um but you want this now to so this b here is like the common um the common commit that you that you both started from someone else push c you push b b and d and now you want your branch should look like this c is loss and only reachable but you can force git to actually do this by sending the force command by setting the force uh parameter on on on the push what you do then is that you're saying that no just move this origin develop branch to d and you don't care that c is lost and so this is why you don't want this to be done on a shared branch because once you see is loss that causes a problem so other people who may have c in their git repository and they would need to recover from that okay so when i say c is lost here it's gone but it's not really because remember the commit graph is depend only so this c here is still pointing to dna you still have this original brand sitting out there it's just not accessible but if you know the commit hash of c you could always get back right back to it okay but there's a small window because eventually c will be garbage collected any any node that that git can't reach via a branch or tag is eventually garbage collected but you have like some i mean generally they don't garbage collect instantaneously so you can always recover if you know c and there are tools also for like trying to find c when there is no way to traverse to it so there are other tools i'll pick up these like sort of orphan notes so you can recover from from something like this if you do it um inadvertently and it's almost very likely that c is also in some other um one of your colleagues repository if they haven't pulled yet so you can also recover that way too right so nothing much is ever lost with git because it's a pen only which is one of the ways that you can actually work with you know git confidently and reliably because you know that the commit graph is depend only okay okay so um we've talked a little bit about pushing changes okay so if the local repository is in this shape this your local develop branch and the remote repository is in this shape it's one commit behind it's a and b and you want the remote repository in this shape you want develop an origin developed to print the same thing and this notation here is actually on purpose in the sense that a branch is just metadata on this commit node when you create a branch in in git you're not laying down new commits or anything you're just adding um metadata that says that develop points to this branch or the origin develop points of this branch or maybe some new branches you created also points to see you're creating metadata that points to your commit graph you're not creating new graphs at all okay so you can make the remote repository the same shape as my graph and once you do this you push your change now it's a b and c and develop and origin develop points the same thing so you were at this shape the repo is in this shape and this is the shape that you want to get to and the way you get there is you you can just push your changes and this work because by the push rule b is still reachable from c so that's a a push that does not lose history okay now if you are making concurrent changes there's two ways to deal with this this is the rebase case right so your local repository is in is a and b and the remote repository is a and c so you both started from a you put on you put down b and someone else has put down c okay so to actually get your changes up to the repository you want your local repository to look like this you want to replay b on top of a and c and so that's exactly what read base does rebase will take your change b here and then play it back on c to produce a c and b and once it's in this shape it cannot be push because by the push rule c is still accessible so that's how concurrent changes work in the rebase workflow the other workflow that you that you may be working with uses merge so the same situation as before you have a b and ac and you want your repository to look at this shape instead so here's a and b here's the here is your original branch here's ac this is what came in from the remote branch and then d is the merge and this is what happens when you do a git pull so if you're at a b and you pull ac what git does is that it first brings down ac and then it does a merge so a git pull i'm sure you've seen this before is get pull is a combination of a get fetch meaning fetch will bring down ac and then merge will then combine ac and a b here into this new new commit d and then now both develop and origin develop will point to d and now you can push this okay now you can push it now because by the push rule c here which is the original commit is still accessible from d so it will allow this push however if you think about like if you have a big team and everyone is using the the merge the merge workflow you can see that there are all these like you know these these non-linear merge paths and if you have multiple of them your git commit graph can look really hairy because there's too many you know there's a ton of branches so this this workflow is generally not recommended um for larger teams because of the large number of of of [Music] non-linear mergers happening any questions about these these changes these ways of merging and rebasing changes there was a question earlier about rebasing but um i believe it got answered uh so okay i think i'm sorry i might i saw i i'm only seeing my um i'm a rather new presenter so i only see my my presentation i don't see any interaction from other people should i try to yeah no worries no worries yeah it was just uh vijay was asking a few slides back um if uh basically was is that the case where you may be asked to rebase and then um two slides after that you covered rebase so i think you've answered this question if not vj please feel free to chime in yeah yeah no all set i think that was a question i've seen that warning sometimes when i'm trying to pull from the remote because the remote has advanced in one way and the local has advanced in a different way yes yeah so this here when you do this uh pull here um the other note i wanted to make was that be sure make sure that you have you update your git um uh get executable to be the very you know close to the close you know close to the newest version i should have checked before this presentation but you know git is actually they continue to refine it for instance um they've they created a new switch for git pull which is fast forward only so it actually prevents you from pulling and creating this d automatically so it only pull if it can produce a learning of his history so i highly recommend you turn on that fast forward only for get pull so that you don't get into this case okay so it'll force you to basically always use uh the rebase workflow instead of of these merge cycles we've got another question kim um from pavan uh how does git stash work in this case of merge does it simply delete the change as it is not yet committed to the local branch good stat is they asking yeah stash okay so the the you do a git stash you're stashing the index so if you go back to the index the index is commit to b right so during the merge and if unless uh if if you haven't committed the index yet the stash you're stashing the commit to b would actually be this d prime here so once you stash this you are back to just a b because ac hasn't been incorporated so once you stash d prime if that's the index area then you're back to this a b here and this and i'll cover stash a little bit too actually so hopefully that'll answer their question cool that's it so far okay okay yeah so stash basically undoes d and leave your repository at a b you haven't lost anything it's just you've lost the uh the merge that git wants to do for you which may or not may or not may or may not be relevant to your use case okay we just got another question so john has a question so generally speaking in larger teams you are better off rebasing your branch and replaying your changes rather than doing a merge yes and if you're using um the sts microsoft or azure is what's called now i can't keep i can't keep track of what they keep calling it but basically the azure um azure devops basically yeah if you use the um pull request mechanism for making code changes so basically you would lock down your develop branch and you allow no one to push changes directly to develop branch all changes must be pushed as a future branch and you must issue a pull request and then furthermore after you do that you can they've just recently in the last six months added a refinement where the only pull request options you have are rebase squash or fast forward basically they'll only allow you to do rebases and they won't allow you to actually do a merge anymore and once you turn that on you would get very linear and get commit histories which are very easier much much easier to um to look at plus you have like almost like absolute safety because no one is pushing anything directly to your develop branch and so yeah so you basically you want to use the rebase workflow but i would say only if you have something like vsts where you can use the pull request mechanism because that makes it completely safe okay hopefully that answers john's question yeah i think you did okay okay um so now we get to races okay so because like if you're on a large team the repo doing peak hours of repo could be changing a lot and when you end of the day as you're pushing changes you may find that people are beating you to pushing your changes so that what by time you push you're already out of date so what happens is your local repo is in this shape so you authorize a and you've now laid down b and that's your local repository the remote repository is now an ac you someone else started a and they beat you to the punch and push ac okay so now to push your changes you have to get your repo into this state because b can reach c so therefore git will allow this by the push rule git will allow this push right so what you do is you rebase your changes a b on to ac and what git does in rebase is that it notices that you're both started at a so it'll take b and it'll replay onto ac and it will produce ac and b so that's pretty basic okay so now you want to push it but before you could touch because like this is distributed so other people could have beat you the punch again so before you push acb the remote people are changed again and someone else has sneaked in d now the repo now is that a c d so you can't push or kid will say well if i push ac in b d is no longer reachable from b so therefore by the push rule it's rejected okay so to push successfully you have to do the same thing again you have to fetch and you have to rebase a c and b on to a c and d and the same rebase mechanism works because they notice that you are both starting at c b is the only difference still you take b and you replay in the a c and d and you produce a c a d and b and this particular commit graph can be successfully pushed because d is reachable from b now you can push okay so the basic strategy here is to just keep on fetching and rebasing until you can actually beat someone else to the punch and push up your changes and this is much easier done if b is your only change and so if you are working with git and you are following the rule of you know commit early and often which i always do right because once you commit something it's you always roll back to it so i tend to commit early and often and i even tend to push my changes onto remote code base the remote repository under my own branch um so when i time for me to like end the day when i'm pushing light changes i may have like five or six from it here i may have b c d and e but if i'm trying to you know do the rebase into other people's code it's much easier if everything is collapsed down into b and that's easily done also and i can also and i'll cover some of that too so this is why this particular slide only works with one one um one commit because that's the state you want your local development to be in before you actually push right so that's just a hint on how to like easier work um with git at the end of the day when trying to push your changes any questions about resolving races here because this can happen pretty often in larger teams and it could cause a lot of confusion when your your your changes can't be commit also you know this slide is also embracing the idea of rebase 2 because there's so many presentations out there so many tutorials out there say like the stay away from rebase unless you know what you're doing but if you understand that the commit graph can only be appended to and you understand the push rule rebase is completely safe and it's really hard to lose data and get anyway okay so i'm currently encouraging people to actually use rebase instead of instead of merging and with this some of these rules in this presentation you should be able to work out what is a safe rebase and what it's not that's that's actually really important too but so i'm hopeful hopefully this presentation gives you the tools to actually make that that uh judgment about what it's safely based or not okay okay so all right so time checked shoot 12 42 um i'm only only like halfway through my presentation this is actually not good uh resetting branches so you can move around the commit graph at will so there's a huge limit graph the current branch moves to the hurricane commits that's the key thing here the current branch and your working directory moves you're moving the current branch you're not moving the commit graph at all you're moving the branch so the current shape is like this a b c and d and you want to rewind your local branch to be here for some reason you can do that right you can actually do git reset which is the same thing as move branch you can say you're on the develop branch and now you want the develop branch of point to b instead so this is what the shape that you want right and so you can do that and but other questions arise though what happens to c and d when you do this and that's where it gives you a choice if you do a get reset hard then c and d are lost on the current branch they don't appear at all it's exactly your branch that b and c and d are just off back on origin develop and and you can then diverge from from this point on okay or you can actually have c and d stay in the working directory as change files and that's when you do the get reset soft and when you do that by the b here the change to c and d here shows up at just change files you just get status you'll see these change files they're not added to the index though so they're just unadded and there's another mode called mix that will actually add it to the index okay but i won't am i going to cover that okay so this is like really key because this is like a really easy way for you then to squash changes right so you have c and d let's say b is where you diverge right b is you had b you've done a ton of work c d and a let's say c and d and you want to collapse them all you can do that via the the reset command instead of the more harder to understand rebase rebate squash commands okay so you do a good reset hard or soft here and then um instead instead of the the work in progress rebate squashing so here you could if you are this is your current commit graph c and d are working progress and you don't want such commits to cut up the graph because it's just working in in progress so you want your graph to look like this instead a b and c and d are combined into one commit so you have three commits instead of four to get there you do it reset soft so this is the state you want this is your current state of the graph this is the graph you want to get to do to do that you do a reset soft producing a b with c and d now as change files in your working directory so now you develop points point to b now you can add those files to the index staging area you produce the cd prime which is the staging area and now you commit it now you have a b and c d then this is three commits instead of four okay so you can do this for any number of commits out here right you can have like 10 commits to the right here if you select back to b you can combine them all in just one fell swoop that's a very simple way to squash your changes instead of using rebase questions real quick i'm going to try just clicking the page here a little bit yep no questions okay okay here's another case where you work on the wrong branch this is fairly typical right so the remote branch looks like this you know change a and b your local branches as you've accidentally checked in c to your local develop branch so right so you've committed and looks like a b and c instead when you want your repo to be in this shape where a b and c is your future branch and a and b is your developed branch okay so you could just create a branch called future and now both your develop branch and feature point to a b and c this is a git create branch command and now you can switch to develop branch and then reset hard back to b leaving your graph in the desired shape right so this is the this is the you report when it looks like this and these commands now have your repo looking like the shape you want okay is that does that make sense i just went through there it does to me i've i've done that many times okay good yeah so you've visualized the graph intuitively and using reset to to get your branches back to the way that you want them to be okay another way to work on the wrong branch and six of these is is using stash that's a little more uh work but it has some advantages of staying on the same branch so the basic uh setup is still the same okay but what you do is you're on the develop branch and what you can do is you can reset soft to b so now developers point to b and leaving your changes in the working directory now you can stash the um what's in the staging area and you so you have this you add uh the changes to the staging area producing the c prime here with the station area and now you can stash c if you stash it you run it get stash now all it does is it takes c here which is the commit to b and puts it into the stash so it's a hint here's a stash it's just a commit actually the stash and the index areas which are mostly the same thing that just commits to b git does a lot of that and it's it's architecture and in the way it's designed where it's reason commits up for almost everything okay so once you stash c prime here your develop branch is like back to exactly what you were looking for and now you can just create your feature branch and you can pop the future branch off from the stash leaving c when you pop the feature branch and then commit it and now you have a b and c it's your future branch and a b is back to available developer which is exactly the shape that you were desiring right so that is i keep on i'm sorry my um and to stop using my mouse pad to do this because i'm changing the presentation too much yeah here's where i was okay so this is exact this is another approach to the working on the wrong branch by using stash instead many ways to do the same operation in git so another thing that um that i use a lot which maybe other people are using is is that you have persistent feature and bug branches and the advantage of doing that is that you never re never rarely create another branch so you don't have a lot of brands to to keep track of so what i so what this does is you have just a small number of branches so what i do is i have a feature branch and a bug branch because i usually don't have the bandwidth to work more and more than one t-shirt one bug at a time okay um so instead of creating new branches if the shape of the current repo is a b and c in the shape of the local repo this is the remote repo a b and c of the changes up there the local the local repo has a and b only and a b and d is my future branch okay in this case the kim feature brand represents uh work that's already merged so i don't care about a b and d anymore so but i stay in this branch and what i want my graph to look like is i want my graph to look like this when i start on my new feature i want a b and c to point be pointed at by both origin develop but also my kim feature branch okay so if i'm in this state right here if i do a fetch what i have is this state where i have the original origin develop i have my kim features all this does would advance a b into c and now i can just move the future branch with the get reset heart the origin develop leaving exactly the state where i want to be when i'm starting a new feature but that is my kim future branch is concurrent with the origin develop branch and you can keep doing this for each um feature cycle where you work one feature you after you push it and issues a pull release um you can start off uh the next time you reuse the same branch and you use the same branch also for for the bugs so it's just another way of working with git a little more efficiently okay all right so yeah getting close to the end here okay so those are some of the use cases that i wanted to like highlight with uh you know with with the commit graph okay so we come next to the idea this is a really super powerful idea that um that cause because commits are universal every single commit is uniquely identified and because the commit also has its history it points to its parents it's the entire history okay so every commit hash ever created shares the same logical universe spanning repository that may sound grand but it's true so my view of git is that your local repository or any repository is just a subset of this universal repository so taking the logical stream your code is in the same logical repository as microsoft's code for windows if they share the same sort of git basic infrastructure of commit hashes just at the repos you have different slices of this universal refill and so furthermore you can move any commit into your own repository and you could push your commit into a repository you know given the push you know allowing for the push rule and all that okay so once you do this though because the commit is also it's history grab you've moved the entire quote-unquote branch so you're swinging commits around and so how do you add commits from arbitrary remote to your own local repository that's where the metadata come in and that's where remotes come in so we don't have time to cover remotes at all but remotes are just pointers to another repository once you add a remote and that's the get remote command once you add a remote you can fetch that remote into your local repository and then you have the branches from the repository in your own and you can then check those branches out and work on them and so this is also also obvious security around this too so you must be allowed to do this but as core git allows you to move any arbitrary repo commit into your own repository okay any questions on on remotes i think they can answer quickly at all okay okay so uh in summary git commands are graph com manipulation commands they're best understood as ways to manipulate your graph and then because graphs are append only what you're really changing is the metadata points to these commits you're not modifying the graphs themselves in the sense you're doing surgery in the graph i guess that's completely disallowed you cannot change a commits parent you're only adding to those graphs and you're changing the metadata the branches and tags and remotes and so forth to point to the commits that you want them to change and git has rules like the push rule to make changes to the metadata deterministic okay so once you understand that then i think it should be much easier to to work with uh with the git commands and not get into into trouble okay so that actually ends my presentation so i can have like five minutes or so that i can take uh calls if peop uh or um take care of questions if people have uh specific questions um that they want answered there's a couple um john do you want to do you have a mic do you want to come off a mutant just ask your question if not i can read it uh sure hopefully you can hear me yep yep okay great yeah i was asking if uh you recommend when you're creating your branches for things do you recommend doing a local first creation and then a push to remote versus a remote first creation and a pull to then do your work i i work the way i work is i do i create the local branch first and then i push and i don't tend to push the branches until i have my first commit but then after i first have my first commit into a local branch then i push as often as possible because that basically puts another copy of my code on a remote machine that i can get back to if i have to mess up my local repository or change my code in a way that i didn't want to be changed yeah so yeah i would create the local branch first and then push it it's just easier that way especially if it's their own private branch too that no one else sees thank you and gary's asking if we can get a copy of your slides yes i would definitely clean that slide up a little bit create a pdf and i'll give that to jason and he'll push those slides up there actually it's beyond just what you presented but also some of the material that you were not able to present okay that would be great i will yes thanks lots of uh great sessions nice sessions thank you here's one have you set up local gets repos yeah and so a local git repo is just like get in it right so every single project that you start can have source code control because the git repo is just a hidden directory inside your root directory so a local repository is just again this command you can turn a directory into a repository and i've actually abused git to use as a way to transfer files to remote machines right to so you create a git repo you add your files to it you push it to some central location and then on your foreign machine you pull that image and now you've transferred x number of files to your new system does that answer your question so a git repo is nothing more than just a local database in your source code directory and that's you want to look at the git init command so feel free to reach out to me on on twitter or via email i think my contacts contact information is on the meetup itself and i will be happy to answer any uh questions you have on git or if you reach some sort of connector with git and want to reach out to me that's perfectly fine too i am more than happy to to help people with their good issues awesome great i uh i don't see any more questions and i'll go postage or um your twitter handle so comments too so we'll get there and steve says a great session thanks yeah thank you thanks for attending hopefully that'll give you all some further insights into git and made it less mysterious awesome great i will um once i stop the recording it's usually like 15 minutes before i get it posted up onto youtube and i'll i'll share the link in the meetup comments and then i'll also send it to kim so she can share it with whoever she wants to okay all right thank you thanks everybody thank you thanks for coming

Channel: DevBoston

Views: 744

Keywords:

Id: iLnegsvzTHE

Length: 55min 41sec (3341 seconds)

Published: Thu Mar 25 2021