Adding Tags to the Repository

Tim Buchalka's Learn Programming Academy
A free video tutorial from Tim Buchalka's Learn Programming Academy
Professional Programmers and Teachers - 1M+ students
4.5 instructor rating • 52 courses • 1,034,803 students

Lecture description

In this lecture we will add some tags to some specific points in our repository's history so that it is easy to identify new versions or releases of the project. Everything will be pushed over to GitHub so releases and tags exist there too.

Learn more from the full course

Git & GitHub Masterclass

Add real world development team skills for version control and source control to your resume & programming arsenal!

11:34:11 of on-demand video • Updated November 2020

  • Use Git and GitHub in the way that modern development teams use them.
  • Understand the ideal structure of a repository.
  • Learn how GitHub will enable great collaboration in a development team.
  • Master the git commands that will help you explore any repository.
  • Leverage Markdown in your GitHub repositories.
  • Publish your repositories in public websites through GitHub Pages.
  • Feel comfortable contributing to a repository, whether open source or as part of your job.
  • Understand how GitHub is the foundation for more advanced development practices such as CI/CD and DevOps.
English [Auto] By now we have made quite a few changes to our gear. Help master class repository. Especially now that we have added some things in many different branches locally but also we made some changes in another repository so we had to actually create a pull request to have that new code right into D or regional repository. It means that it's time for us to mark these version as the first release that we may have ready for our users. And of course because eventually we're going to have more releases. It is a good idea to know that right here at these moments in the history of our repository we have Version 1 ready. And so during these lecture we're going to learn how to create thing they use called tags inside of a repository so that we can identify those versions eventually going to start doing that directly from the terminal. So let me just go ahead and clear the terminal here. Of course right now I am locally on my get good help Master class project. And one thing that I have to do right now is actually pull the changes from their mode because it contains a new merge due to the pull request that we created in a previous lecture because once I have all of the history up to date which apparently I don't see and because I make a tiny tiny modification here you can see how get identified a few space characters that I deleted in here but let me just go ahead and discard that that changed. Now if I wrong get stanzas everything is off today. OK so I have my local repository of true data with the remote nothing new locally. It is time for us to add the attack in here and I think the time is going to be quite easy. All I have to do is execute a grid tag. I'm going to add at dash a primary here and has the name and my tag. Let's call this V 1.0 for version 1.0 and submit it to the commits. This is going to contain a message. So as we have done many different times when committing I am going to add a dash and parameter and interval quotes the message that I want is to contain. So this is the first public release of our amazing Web site. So let's just execute this. And now if we go ahead and execute give law we're going to see that in the last comment that we have made which is that merge request there is now a new tack. Now you might have noticed that there were some tax in the other report that we have been using the HCM L5 boilerplate repository. So pretty much the onus of that repository had added those tags so in case you notice them. That's what this means. Essentially we created attack at a particular point in the history of our repository. So eventually we know that at this point we had a first version of our code or of our project ready to be released. And let me go ahead and do another command in here so I can show you a little bit more about this. Thank you for executing the show. And I use v 1.0. We're going to see exactly the information about that particular attack. So for one I have information about who attacked that command which lost me when was attack and notice also that message that we added when creating the attack. And also of course information about the command to each attack is pointing to now there is also a slimmed down version of tagging but those tanks don't contain information about a tagger and a date. So I don't usually use those kinds of tax. Other times though this is exactly the kind of target that you want to create. Now when creating a tag as you have seen it immediately assigns to the most recent commit. But of course we can assign tax to previous comments in case we forgot what attack somewhere. So let's say that in these same repository I want to add a better DAC to one of the commits maybe we had a beta version of our code and I just forgot to add a tag but I do want to be able to go back to that version very quickly. So let me just clear the terminology here and execute first and foremost we'd like to take a look at the comments and figure out the one that I want to assign the new attack to. And I'm actually going to be using a slightly different version of the law command. So in here I can actually use dash dash pretty literally equal to one line which is actually going to show me all of the commands just like the normal law command boards it's going to display them in just one line as I am suggesting right here with this parameter. And of course each and every one of them is this deal going to contain the title of the committee so I can quickly identify the committee that I want so I can see of course the one that is already assigned a tag v 1.0. Let's say that the one we hear is the one that I want to set as debate attack. So let me just go ahead and select their first few characters of this share and quit this section here. And I am also going to say that the tact that you commit the command is pretty much the exact same thing as before except we now have to specify a share. So I will simply go and execute tag. Again e it's going to be dash a I'm going to call this beta and then right after establishing the beta I am going to establish this sharp. Of course I can still add a message. Let's say that this is going to be beta version ready. And now if I execute get law again I see that indeed these commands contains that new task. So there you have it this is how you assign tacks here on and get so you can identify in which commands you had a specific new version available it is going to be now easier to join from one version to another or to understand at what point in the history of your repository you had a new version ready. And of course this could be anything. You could assign V one point one for example one point zero point one etc.. Now so far this tax are actually not over on github and bushing over to GitHub. E not going to do the trick. In fact if we execute get statues we see that everything is up to date. So there is really nothing to push over to the remote at least not when it comes to comments boards. I can still try ambush over to origin their tax so all I have to do is add dash dash tax here at the end of the Bush comment and this is going to go ahead and push all of the tags that we have added over to the remote and you can notice that indeed there are a couple of new tags that have been added. The beta and the v 1.0 attacks. Now if we navigate over to get hub and reload Arab repository you're going to find over here to New tax and it's going to say to release us. And indeed you're going to have the information about V 1.0 pointing to a specific commit and the beta. Also pointing to a specific comment. If we expand this we can see their message that we added when adding the tag but also notice something rather interesting. There is as I said an entire files. So these are actually snipped versions of our repository. If I go ahead and open this c file let me just extracted and show you what is inside of it. This is pretty much the exact same thing that we know exists inside of our repository. And now if we head back over to GitHub you can see also the tags I have where you can just take a look and attacks again with the same kind of information in case there weren't any releases of a specific tag. You can just come here and create a release in this case. We have a release for each of these attacks. That is why we see them listed right here in the release as death. In addition to that instead of GitHub you actually have an easy way to jump over to a specific version from the code tab if you navigate over to the branch selection element in here. There is also in addition to branches at tags section. So here you can select either one of the tags that you have and jump over to Dad's specific point in the history of the repository. So notice that in this case we're going to see the repository as it was at the moment that he was tagged as beta. So it's just basically something that we have seen before identifying a specific commits and never getting back in time to that point in the history of the repository. That now points to these comments. But of course everything else is just in here. So throughout this whole section we have done a lot of stuff. We started it by evaluating how s it that marriage conflicts happen and then over on our local repository we created a couple of branches made some changes here to the index reached the email file and notice that if we tried to merge damn there was a conflict. We learn how to solve that conflict and push everything over to our remote den. We actually used that seem remote from a different repository different github account so we actually have this geared you'd have master class repository that exists an entirely different account. We also made some changes and we're pushing them over to the original UN repository with a pull request. We found out that there were also some merged conflicts. We learned how to solve those merge conflicts here on GitHub directly so everything is now working perfectly right from the original gate up masterclass repository. And finally we just learn how to add tags to specific comments instead of our history. Now in the next section we're going to work a lot more with GitHub because there are just so many different things that we can do right here that we haven't covered yet. And that is just going to make collaboration on GitHub such a powerful tool and so are the things that we're going to do are actually requests which we should be a little bit familiar with by now. But now covering a few more of the GD have features that are available that will just make collaboration at Bree's.