Welcome to Git Feature Branch Workflow – Working in Branches. After watching this video, you will be able to explain what Git is and why it’s used for DevOps, analyze the workflow of working with Git and the Git Feature Branch workflow, and understand how developers work within Git branches when creating a new feature. Git is a distributed source code management tool used by developers worldwide. It was invented by Linus Torvalds in 2005 for Linux kernel development and is now the most widely used version control system. Code can be completely local, or it can be kept in a remote repository so that developers can collaborate. Every developer also has a full copy of the code. This differs from other version control systems that may only have developers check out the part of the code they are working on. This means that developers can work locally and track changes without having to contact a central repository every time. If something were to happen to the central repo, you would still have an entire copy locally to rebuild from. There are many ways to use Git in practice. Some of the most popular repository hosts are GitHub, GitLab, and BitBucket. Git is the current standard for version control software. It completely changed how developers do their job, allowing them greater control over their code, and the ability to roll back changes precisely if needed. GitHub is one of the largest platforms that developers can use to implement Git into their workflow as GitHub hosts open-source projects for free. This has enabled Developer Operations (or DevOps) methodologies that previously lacked a good way to implement them. DevOps benefits from Git because it can handle projects of all sizes, enables non-linear collaboration, and tracks version control to ensure code quality. Let’s look at how Git is used in practice. Here, we’ll demonstrate some of the most important steps and commands in an example Git workflow. Teams are free to adapt other workflows as well. Once a developer has made changes on their local clone of the code repository, they can run `git add` to move those changes to a staging area. The staging area allows developers to clearly separate the changes they want to commit, which may not be all their changes. I like to think of it as a shopping list. What do I need to buy the next time I go to the store? The staging area is your commit list. What file changes do I want to persist the next time I make a commit? This gives developers an area to double-check they have exactly what they want to change ready to push. They can then run `git commit` to commit those changes to the version history of their local repo. This doesn’t affect anyone else. It just changes the local repo. From there, the developer can continue working, or finally push their changes to the remote repo using `git push`, where everyone can see and access those changes. For another developer to get those changes locally, they can run `git fetch`, to fetch the most recent metadata of the remote repo, which describes all the version history and branch information, but it does not actually pull the newest code changes. It allows developers to check if there are any changes without actually pulling any changes. This is so developers can avoid any potential merge conflicts. To get the actual changes, and to download and merge their changes into their own workspace, they can run `git pull,` which will pull the most recent version metadata and any changes. If a developer wants to work on a specific branch of code locally, they can run `git checkout` to switch their workspace from one branch to another. Git looks in the metadata and makes changes to your local repository to show you exactly that branch’s code. You can also use `git checkout` to get back to a previous commit. So, this is great if you’ve gone down a path, you’ve made some changes, and then you decide this isn’t working for me, I want to get back to the last thing I committed. Just do a `git checkout period` and that will get you back to your last commit. If a developer has made a commit but realized that their changes are incomplete or incorrect, they can run `git reset --soft` to undo that commit but keep their changes in the staging area. Once they’ve made the necessary fixes, they can commit those changes once again. The last command is `git reset ---hard`. It’s a very powerful and dangerous command. It will erase all changes made locally to a specific commit. So be mindful when using this command. This slide shows you the power of Git and how it can be used in a development process. Now that you understand the Git command workflow, we can look at how the Git Feature Branch workflow is used in social coding, visually. You start by cloning the repo (if you don't have it on your local computer), and then creating a branch. You want to make sure that you create a new branch for every new feature that you work on. Then as you're working on your code making changes, you’ll want to commit those changes. A commit gives you a checkpoint to go back to, so don't be afraid to make as many commits as you need. At some point, you're going to want to push those changes to a remote branch. This is like having a remote backup, so it’s recommended you push your changes to a remote branch as often as needed; at least once a day. Then you open a pull request. It might be when you're finished, or it might be in the middle of doing development because you need to show people your code and ask questions. This is where discuss and review comes into play. This is all part of social coding. Once your changes have been reviewed, they will then get deployed to testing. And once all the tests have passed, then you could merge the code back into the main or master branch. Here’s a sample workflow that developers may go through when starting development on a new feature. When using Git, always make sure you start off with the latest code. Check out the main branch and pull the new changes to your local workspace. When working on a new feature, make sure to create a new branch to work from. This is when a developer is ready to start developing that new feature. Once you’re finished with your changes, you should stage your changes using the `git add filename` or `git add period` command and commit them with a good, descriptive message. Be careful with ‘git add period’. Make sure you have a good .gitignore file otherwise you may check in files that you didn’t intend to. You can always use ‘git status’ to see what’s going to be committed. Only after that can you push your changes to the remote repo and track the branch that your changes are on. The ‘dash u’ option followed by the remote branch name are only needed the first time to create the remote branch, and any subsequent commits can be pushed without them. The whole process has three key components. We want to work off the latest code available, create a new branch to store our changes, and set up a remote branch to push our changes to. Say the next day you did some more work and now you have new changes to push. You would perform the same process as before. Add your code to the staging area, commit it with a descriptive message, and push that code to the remote repository. In this video, you learned that Git is an essential tool that enables DevOps and has many commands that provide essential functionality, the Git Feature Branch workflow is a process that many developers use in their job to develop clean, concise, and high-quality code, and as a developer, using the Git Feature Branch workflow is essential if you want to take advantage of all the benefits Git can provide.
