Git & GitHub Masterclass

Now that you have started using Git, we will start using GitHub as well, but before we dive into the GitHub tool, we first need to undestand how does it fit into the Git environment, how would we use it, and how does it differ from Git itself.

In this lecture you will create your GitHub account and start exploring the website. You will then create your first repository over on GitHub, which won't mean that it substitutes the local usage of Git.

In this lecture you will send your local repository to the repository you created over on GitHub, this will actually be a single repository that exists on more than one computer. So this is all about continuing to use Git commands and Git working together with GitHub

GitHub is not an editing environment, but for small modifications it can be of use. In this lecture we will change the code that we have been using a little bit, and make sure that we commit the changes.

So GitHub can make changes and commit them to the repository. In this lecture we learn how to get those changes in our local repository, since it would now be out of date, since the remote made some additional changes.

Working with a remote adds another level of complexity to our version control that we hadn't seen locally: we may miss updates that others make in the remote. So git status becomes of great importance to check for updates that have happened outside of our local repository.

You now know more about GitHub as well as about Git. The next step is to learn how GitHub can help you colaborate with other developers, even those you don't know. Here forks play an important part, and it will be all about copying a repository into your own GitHub account, but before diving into that, we need to introduce the concept and understand how that would work.

Now that you have a fork of someone else's repository over on your GitHub account, it is time to "download it" into your local computer so that you can use Git locally and your own code editor to work on the project.

After cloning a repository a great thing to do is explore the logs that give you information about the versions that the repository has had over time, and exploring the logs is a great way to do so.

You have forked a repository and started exploring the history of the commits made, but digging deeper into the individual changes made to individual files is also of great importance.

All the things we have learned about exploring details from a repository are deeply integrated into GitHub, which just leverages what Git has to offer and presents the information in the website. In this lecture we explore file details, blames, and commit history directly from GitHub.

Making changes to a repository that you cloned is the same as making changes to a repository that you created. We also explore what it means in the context of collaboration, and get a sneak peak at what pull requests are.

Version Control is about being able to go back to a previous version of our code if things are no longer working the way they were supposed to. So during this lecture we focus on the steps that you can perform to go back to previous versions of unstaged files, staged files, and even commited files.

In this lecture we explore the main good practices when working with branches for ensuring that you always have a working final version of your project, and that you correctly structure your branches in a way that is easy to understand the relationship between them

In this lecture we will dive deeper into what a branch is, and how are we going to be using them to add new code that is related to a certain bug fix or some new feature that must be added to the project.

In this lecture we finally create a branch inside of our repository. This new branch is going to be the dev branch that I mentioned in the previous few lectures. We will also create a feature branch and make sure that it doesn't affect the other branches until we have tested. Just for fun, we will add some Bootstrap to an html file that we have used before.

In this lecture we finally create a branch inside of our repository. This new branch is going to be the test branch that I mentioned in the previous few lectures. We will also create a feature branch and make sure that it doesn't affect the other branches until we have tested. Just for fun, we will execute the beginnings of another pull request.

In this lecture you will learn how to use the gitignore files so that some of the files in the working directory are ignored by git and hence are not added to the repo.

In this lecture we will push the local branches to the remote so that it contains all of the branches that we have created, and will also checkout to the remote branches locally (and track them) so that both repositories contain the same code and git information about all the branches

In this lecture we will take a look at a neat git tool that allows us to graph the relationship between the branches and the commits, as well as understand where and whit which commits did merges happen.

Merging branches is a very important step. This lecture covers how you can merge branches using Git directly from the terminal, but also mentiones that there might be more complex scenarios in the future.

Merging branches is a very important step. This lecture covers how you can merge branches using GitHub (where this is called pull request), but also mentiones that there might be more complex scenarios in the future.

Once we have executed some merges without any issues in the process, we will take a look at when would some conflicts happen, since merges may not always be executed automatically by git

In this lecture we will now talk about the types of merges that we have already executed, so we understand how the may be graphed in the terminal when executing the log command, and also, so we identify the reason why no merge conflicts have happened just yet.

In this lecture we prepare a scenario that results in a merge conflict, and inspect how is it that the conflict is handled and depicted by git from the terminal and in the file itself.

In this lecture we will solve the conflict that we prepared in the previous lecture so the merge can finally happen. Then, we will try to push the new merging commit to the remote, only to find that there are a couple of other simple merge conflicts that we have to solve first.

In this lecture we build over to a merge conflict on GitHub when executing a pull requests, du to our different edits to the same files from two different repositories that we forked from the original repo.

In this lecture we solve a merge conflict on GitHub that generatedn when executing a pull requests, we will also have a sneak peak to collaboration directly from the GitHub website by adding comments from the pull requests and using markdown a little bit.

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.

This lecture is going to prepare you for this and the next section, you will learn to add collaborators to a private GitHub repository, and to clone the repository to a Google tool called Colab, where you can edit the files (python notebooks) that we will be using.

In this lecture we will learn how to protect branches in GitHub so no merges can happen without first some reviewers approving the changes. This adds to the pull requests a new level of protection, even from the collaborators that have been added to the repository.

Pull requests are very imortant, so there have to be some limitations to how they are performed, which is why we have protected some of our branches. In this lecture we learn how reviewers can comment on the pull requests, request changes, and eventually aprove them so the merge can occur.

In this lecture we will create some issues that describe a problem that we may have to solve with our project, later, when we commit changes, we will learn how we can reference the issue that is being solved, and keep referencing pull requests and issues back and forth

This lecture is all about preparing your repository for people to start contributing to it. It is about protecting branches, setting the repo as public difectly from GitHub, and preparing one of the key files inside of any repo: the README.md file

GitHub uses some templates in the form of markdown files to establish the content that will be generated by default when people create new pull requests and issues. This lecture is about creating the templates that will be used when reporting a bug, when requesting a new feature, and also about readying the file that prepares users for contributing

In this lecture we will use some cool parameters of the git log command that will enable us to create some powerful and quick filters when exploring the commits that have been created in a certain repository. Filtering by author, date, and text in the commit message is covered in this lecture.

In this lecture we are going to work through an entire contribution flow, now that the owner's repository has the templates in place and that we have forked the reository. This flow takes us through making changes to the code, commiting them to a feature branch, creating a pull request, and eventually syncing the original repository back with our fork.

This lecture we talk about the importance of feature branches, how you will be expected to use them, and even the naming conventions that you will likely be following.

In this lecture we go through the importance of descriptive commits, comparing what it would be to experience a list of commit messages in a limited space like the terminal when the are not concise and descriptive, versus ones that are. Finally we offer 6 guidelines to creating the commit messages so that they are always easy to read and communicate the changes correctly.

In this lecture we will cover the places where markdown is supported, of course focusing on GitHub, but also outside of this context. We will also talk about some of the things that markdown can do such as text formatting, adding images, and working within issues, pull requests, comments and md files

In this lecture you will start to use markdown to create and edit an md file that displays the markdown text in a rich format. This lecture focuses on the basics of text formatting for setting bold, itallics, scratched, quotes and header texts.

In this lecture we are going to create ordered, unordered and checkbox lists and learn how is it that GitHub is going to display them and use them as metadata. We will take a look at the syntax needed by GitHub to correctly display sublists, and commit everything in a new branch.

In this lecture, following on the markdown practices, we will learn how to create tables inside of the md files or any markdown entry for that matter, along with how to create links to external sites. Also, we will learn how to align the content of a column in the tables using a simple syntax in the separating line, before commiting everything to a new branch, and creating a new pull request.

In this lecture we will learn how to display images in our md files, comments, issues and pull requests using markdown in three different ways: using an image that is already on the internet, uploading it to our repository to access it locally, and ifnally uploading it to github user content.

In this lecture we are going to cover how to add code blocks to our markdown files and comments, as well as learn how is it that we can tell those blocks to format the code for a specific language.

In this lecture I will present a tool that will help you create markdown files so you can easily design your md files and export them along with images for you to use them on GitHub.

In this lectire I will introduce GitHub pages as a tool that we can use to take our repositories and convert them into a website that helps us display the information that is inside them, whether that is HTML and CSS code, or Markdown. I also mention Jekyll, which will make our lives easier by providing awesome themes that can be applied to our pages.

In this lecture I will mention a couple of tims when creating the md (markdown) file that will eventually be usef by GitHub Pages as the content of your site, so that the visitors of your site can easily navigate between the projects that you will be shocasing.

Now that you have the markdown file ready in a new GitHub repository, in this lecture we will publish that repository as a GitHub page that uses the README.md file as the content, and integrates Jekyll in the form of a theme that makes the site look much better

In this lecture I will mention the advantages and disatvantages of relying on the git integration that exist in different IDEs and cover hoe most of the time you still want to keep practicing how to use the terminal just so you are able to always execute any git command that you may need.

In this lecture we will explore how Android Studio uses git and GitHub for version control by executing some commits, creating new branches, merging them, and pushing to a remote repository that can be created on GitHub directly from the IDE.

In this lecture we will explore how Xcode uses git and GitHub for version control by executing some commits, creating new branches, merging them, and pushing to a remote repository that can be created on GitHub directly from the IDE.

In this lecture we will explore how Visual Studio Code uses git for version control by executing some commits, creating new branches, merging them, and pushing to a remote repository -that we created on GitHub- directly from the IDE.

In this lecture we will explore how Visual Studio 2019 uses git and GitHub for version control by executing some commits, creating new branches, merging them, and pushing to a remote repository that can be created on GitHub directly from the IDE.

In this lecture we will explore how Visual Studio for Mac uses git for version control by executing some commits, creating new branches, merging them, and pushing to a remote repository -that we created on GitHub- directly from the IDE.

In this lecture we will explore how IntelliJ uses git and GitHub for version control by executing some commits, creating new branches, merging them, and pushing to a remote repository that can be created on GitHub directly from the IDE.

In this lecture we will explore how Eclipse uses git for version control by executing some commits, creating new branches, merging them, and pushing to a remote repository -that we created on GitHub- directly from the IDE.