**Using Git Branches to Manage Different Versions of Your Code**

When working on a software project, it's often necessary to have multiple versions of your codebase running simultaneously. This is where Git branches come in - a way to create separate lines of development that can be worked on independently without affecting the main version of the code. In this article, we'll explore how to use Git branches to manage different versions of your code.

**Creating a New Branch**

To start working on a new branch, you simply need to type `git branch` and enter a name for your new branch. This will create a new branch from your current point in history, and it will be listed alongside the main branch when you run `git branch` again. For example, if you're currently on the main branch, running `git branch dev` would create a new branch named "dev" that you can switch to.

**Switching Between Branches**

Once you've created a new branch, you need to switch to it in order to work on it. This is done by running `git checkout dev`, which will change your view of the files to show only those in the "dev" branch. You can then add new files to this branch, commit them, and switch back to the main branch when you're finished.

**The Benefits of Branching**

One of the key benefits of using Git branches is that they allow you to work on different versions of your code without affecting the main version. This makes it easier to test new features or fix bugs without disrupting other parts of the project. For example, if you're working on a new feature for version 4.5 of your software, you can create a new branch from the latest commit and start making changes. When you're finished, you can switch back to the main branch and merge the changes in.

**Git Tags**

In addition to branching, Git also provides a way to give specific points in history friendly names using Git tags. A tag is like a bookmark that allows you to refer to a specific point in your history by name rather than by hash code. This makes it easier to identify specific versions of your code and switch between them.

Companies often use Git tags to mark the release of new versions, such as beta or release candidate builds. These tags can be used to automate the build process and deploy updates to users. For example, a company might create a tag named "beta-1" for a specific version of their software that's still under testing. They can then use this tag to trigger an automated build and deployment process.

**Git Tagging in Practice**

When you first create a new file or make changes to your code, Git doesn't know about it yet. To get it to recognize these changes, you need to tell it using the `git add` command. Once you've added all the changes, you can commit them using `git commit`. The commit message is used to describe what changes were made and when.

Once you've committed your changes, you can use Git tags to give specific points in history friendly names. For example, if you want to mark a specific point in your history as version 1.0, you might run `git tag v1.0` to create a new tag with that name. From then on, you can refer to this point in your history using the `v1.0` tag.

**Conclusion**

Git branches and tags provide a powerful way to manage different versions of your codebase. By creating separate branches for each version or feature, you can work on them independently without affecting the main version. Git tags also allow you to give specific points in history friendly names, making it easier to identify and switch between different versions. Whether you're working on a small personal project or a large-scale enterprise software development team, understanding how to use Git branches and tags is essential for managing your codebase effectively.

**Git Branching and Tagging**

Git branching and tagging are two related but distinct concepts in Git.

**Branching**

Git branching allows you to create separate lines of development that can be worked on independently without affecting the main version of the code. This makes it easier to test new features or fix bugs without disrupting other parts of the project.

**Tagging**

Git tagging allows you to give specific points in history friendly names, making it easier to identify and switch between different versions.

**Best Practices for Branching and Tagging**

Here are some best practices for using Git branches and tags:

* Use meaningful branch names that describe what's being worked on.

* Use tags to mark important points in your history, such as releases or milestones.

* Automate the build process and deployment of updates using Git tags.

* Use Git tags to trigger automated processes, such as building and testing code.

By following these best practices, you can get the most out of Git branches and tags and improve your workflow when working with version control.

"WEBVTTKind: captionsLanguage: enone thing that git is known for is version control in fact that would be for some people the first way to describe it i described git as protecting code but you could describe it as protecting versions as well versions is a thing which drives me insane when you come and you find somebody who's called a video dot final or underscore final because you just know there's going to be a change to it and there'll be final final or new final or final new final what what does git do it's good to think about things like that because you would end up with software doing the same and i had a friend in the company and they were producing versions of software and someone wasn't conforming to the company style of naming things and was creating new version 4. new you know and all these these things but yeah so actually software has a pretty strong history of having inversion numbering scheme for example if you look at the latest version of chrome or chromium it's like version 98.0.4758.81 that time of recording yeah at the time of recording um or that might be the current version i've been stored which is when i last updated it but still like this is so what's that version 98 is the major one and then point zero is the latest minor iteration of it and then points four seven five eight is the latest patch to it um but what they're doing at the same time is they're maintaining older versions so you can at any time if you want to you can install version 94 of chromium just by going to their open source community and then downloading an old version and if you really want you can um it's quite interesting with premium you can see the latest commit that a developer has put into the chrome repository and you can download that whether it works or not you know as a developer you can download it but the point is they've created these versions and they're using git to manage this version history and uh they are using what's called branches within git to manage old versions that they need to update so there might be like a patch to an old version which has new feet doesn't have certain new features of a new one but someone's using because it's compatible with something else but it still needs a security fix absolutely so whenever they find a vulnerability they say okay we need to update you know like windows 8 if anybody's still using that we need to make sure that's secure so they've got to somehow go back to download the code for windows 8 make that patch to it and then release probably 8.10.75 which is the latest patch to it and you can see this in like when you get new release notes you know if you're on your phone and like netflix updates to the latest version you get these release notes saying you know version 17.5.8 has these things fixed and it will have like a little description of what they updated but what they do is they have these kind of past versions built into what's called a git branch so that branch then can then exist forever and they can you can then switch your code view to that branch in the history and say i want to update you know version 16 in case anyone's still using it um with this fix and then commit to that and then okay let's check out the main branch again and we'll make updates to the main branch which is what our main job is so you find companies use these kind of product release branches essentially to store long term in parallel with the current new updates other old versions they can update so in the first video we did we talked about having like a linear history of all your past versions at some point you can say okay i want to branch that linear history into a tree and you can switch between those trees essentially using the git branch command one thing you can do first is you can type in just git branch and it will list all the things you have and for most people if they've never created a branch before that just shows you the main branch that you're currently on and it will have a star next to it that's the one that's showing you if you wanted to see if you wanted to create a new branch which is like for developing a new feature for example you could type a git branch and then have a name and that will create a new branch from your current points uh and then it will be listed if you type git branch again as being one of the branches you could switch to do you call that one new or final yeah new french so actually that's a really complicated issue because um teams that are working on codes there might be 100 developers and they all might need to create a temporary branch so they've got to have some sort of naming scheme so it's a good point to make while you're there um but so if you then want to work on that branch then you have to get check out that branch so you have to kind of choose to switch your view from the main branch and then say okay now i want to view this new branch which you might name you it could be called dev branch and then what that will do is it will change your folder view which i mentioned before to show in the files that are in that branch that means you could then add some new files in that branch you could then commit them to that branch then if you get check out the main you'll see those files disappear temporarily although they're stored somewhere in your docket folder as compressed objects you've chosen to view the main branch and so it will hide all the ones that aren't related to the main branch and then when you get check out the dev branch it will then bring those files back to you and show them to you so it's a it's a kind of handy way of switching between versions basically so that means these companies that have created uh like a version 4.45 of their software um they can if they ever want to switch to it they check out you know branch version 0.45 and then they could work on it and then see those files and they can check out the main again or whichever one they're supposed to normally work on we can also talk about git tag so git tag is kind of a handy feature where you can name a point in your history with a friendly name so instead of saying i want to check out this hash code of like a past commit you can say okay there is one point in time which is when we finished version 4.5 and we can give that a friendly name so if i ever want to i can say git checkout 4.5 and it will just download 4.5 for me so it's a way of giving things friendly names you can use a lot of companies use like a b in their naming scheme for beta or rc for a release candidate which is when they think that this the updates this branch are almost ready to show to the public and then they will show them to like a certain outlet of potential users who test things as a release candidate um and then they will so they'll name it they'll get tag it with that release candidate id so that they can then share a specific friendly named version with people to download and companies will have all sorts of automation scripts which will take anything that's given a git tag and compile it as a ready-to-ship product and test it on a server and then deploy it to a point where people can download and automatically update the website to say there's a new version you could build all those things in but in practice the fact that they're named with git tag as a command is what's important so what happens is uh when you first create a file create file in there and make my files green just represent there's a box and i call that version one at this point git doesn't know anything about that because you haven't told it about it so to get get to know about it we have to do it and i think mike's going to demonstrate this in a second is that log4j is like milk it's like water it's everywhereone thing that git is known for is version control in fact that would be for some people the first way to describe it i described git as protecting code but you could describe it as protecting versions as well versions is a thing which drives me insane when you come and you find somebody who's called a video dot final or underscore final because you just know there's going to be a change to it and there'll be final final or new final or final new final what what does git do it's good to think about things like that because you would end up with software doing the same and i had a friend in the company and they were producing versions of software and someone wasn't conforming to the company style of naming things and was creating new version 4. new you know and all these these things but yeah so actually software has a pretty strong history of having inversion numbering scheme for example if you look at the latest version of chrome or chromium it's like version 98.0.4758.81 that time of recording yeah at the time of recording um or that might be the current version i've been stored which is when i last updated it but still like this is so what's that version 98 is the major one and then point zero is the latest minor iteration of it and then points four seven five eight is the latest patch to it um but what they're doing at the same time is they're maintaining older versions so you can at any time if you want to you can install version 94 of chromium just by going to their open source community and then downloading an old version and if you really want you can um it's quite interesting with premium you can see the latest commit that a developer has put into the chrome repository and you can download that whether it works or not you know as a developer you can download it but the point is they've created these versions and they're using git to manage this version history and uh they are using what's called branches within git to manage old versions that they need to update so there might be like a patch to an old version which has new feet doesn't have certain new features of a new one but someone's using because it's compatible with something else but it still needs a security fix absolutely so whenever they find a vulnerability they say okay we need to update you know like windows 8 if anybody's still using that we need to make sure that's secure so they've got to somehow go back to download the code for windows 8 make that patch to it and then release probably 8.10.75 which is the latest patch to it and you can see this in like when you get new release notes you know if you're on your phone and like netflix updates to the latest version you get these release notes saying you know version 17.5.8 has these things fixed and it will have like a little description of what they updated but what they do is they have these kind of past versions built into what's called a git branch so that branch then can then exist forever and they can you can then switch your code view to that branch in the history and say i want to update you know version 16 in case anyone's still using it um with this fix and then commit to that and then okay let's check out the main branch again and we'll make updates to the main branch which is what our main job is so you find companies use these kind of product release branches essentially to store long term in parallel with the current new updates other old versions they can update so in the first video we did we talked about having like a linear history of all your past versions at some point you can say okay i want to branch that linear history into a tree and you can switch between those trees essentially using the git branch command one thing you can do first is you can type in just git branch and it will list all the things you have and for most people if they've never created a branch before that just shows you the main branch that you're currently on and it will have a star next to it that's the one that's showing you if you wanted to see if you wanted to create a new branch which is like for developing a new feature for example you could type a git branch and then have a name and that will create a new branch from your current points uh and then it will be listed if you type git branch again as being one of the branches you could switch to do you call that one new or final yeah new french so actually that's a really complicated issue because um teams that are working on codes there might be 100 developers and they all might need to create a temporary branch so they've got to have some sort of naming scheme so it's a good point to make while you're there um but so if you then want to work on that branch then you have to get check out that branch so you have to kind of choose to switch your view from the main branch and then say okay now i want to view this new branch which you might name you it could be called dev branch and then what that will do is it will change your folder view which i mentioned before to show in the files that are in that branch that means you could then add some new files in that branch you could then commit them to that branch then if you get check out the main you'll see those files disappear temporarily although they're stored somewhere in your docket folder as compressed objects you've chosen to view the main branch and so it will hide all the ones that aren't related to the main branch and then when you get check out the dev branch it will then bring those files back to you and show them to you so it's a it's a kind of handy way of switching between versions basically so that means these companies that have created uh like a version 4.45 of their software um they can if they ever want to switch to it they check out you know branch version 0.45 and then they could work on it and then see those files and they can check out the main again or whichever one they're supposed to normally work on we can also talk about git tag so git tag is kind of a handy feature where you can name a point in your history with a friendly name so instead of saying i want to check out this hash code of like a past commit you can say okay there is one point in time which is when we finished version 4.5 and we can give that a friendly name so if i ever want to i can say git checkout 4.5 and it will just download 4.5 for me so it's a way of giving things friendly names you can use a lot of companies use like a b in their naming scheme for beta or rc for a release candidate which is when they think that this the updates this branch are almost ready to show to the public and then they will show them to like a certain outlet of potential users who test things as a release candidate um and then they will so they'll name it they'll get tag it with that release candidate id so that they can then share a specific friendly named version with people to download and companies will have all sorts of automation scripts which will take anything that's given a git tag and compile it as a ready-to-ship product and test it on a server and then deploy it to a point where people can download and automatically update the website to say there's a new version you could build all those things in but in practice the fact that they're named with git tag as a command is what's important so what happens is uh when you first create a file create file in there and make my files green just represent there's a box and i call that version one at this point git doesn't know anything about that because you haven't told it about it so to get get to know about it we have to do it and i think mike's going to demonstrate this in a second is that log4j is like milk it's like water it's everywhere\n"