A Beginner's Guide to Using Git to Push Code to GitHub

[00:00 - 00:09] Now that our project structure is set up for scroller, wouldn't it be creative other people could see our code? For this course, we'll be using the source control software Git, which will be hosted on GitHub.

[00:10 - 00:13] Let's get started. So what is source control?

[00:14 - 00:19] Source control is a way of managing changes to code. It allows us to track the history of code changes.

[00:20 - 00:30] The most popular source control software is Git. Since Git is distributed, this means our code lives on a server somewhere else, and we perform changes locally on our computer.

[00:31 - 00:41] GitHub is a popular choice and being the server part of this. A distributed system allows for different collaborators to work in the same code base without changing code beneath each other's feet.

[00:42 - 00:48] Branches in Git are a way of encapsulating changes. There are many different branching strategies such as GitHub Flow and Git Flow.

[00:49 - 00:58] Each provide a framework on how to develop features, fix bugs, and release code . The most popular and open source in GitHub, of course, is the GitHub Flow branching model.

[00:59 - 01:11] The GitHub branch in Flow starts with a main branch, or master branch in older repositories. Any code in the main branch should be deployable, or in other terms, anything in main should be tested and functional.

[01:12 - 01:29] When a new feature or bug fix is being developed, a developer will create a branch from main, generally called feature slash, a description of the feature, or bug fix slash description of the bug fix. Any code changes will be performed within this branch committed and then pushed to the main repository in GitHub.

[01:30 - 01:42] It is then a pull request is created into the main branch. A pull request is a chance for project owners, other developers, and automated scripts to review the code changes and mark them either as ready to merge or needs more work.

[01:43 - 01:50] Once everything looks good, our code is merged and applied to the main branch. Navigate to github.com.

[01:51 - 01:55] If you don't already have an account, create a new one. GitHub is a free and open repository for code.

[01:56 - 02:12] Once logged in to GitHub, on the top of the screen, look for a plus icon and select new repository. Here we can create a new repository that will hold scroller.

[02:13 - 02:16] We'll need to give it a name. In our case, we'll just use scroller.

[02:17 - 02:23] Next, we can give a description of a library. We'll say my awesome scrolling library.

[02:24 - 02:32] We can ignore the rest of these options and go straight to create repository. Welcome to the home of our library.

[02:33 - 02:38] Let's get our code deployed on GitHub. Open a terminal and navigate to the scroller project.

[02:39 - 02:46] We'll need to initialize git in our project before we can connect to GitHub. Run git init to initialize a new git project.

[02:47 - 02:56] Out of the box, git will track all files that git was initialized in. We don't want all our code being tracked by source control.

[02:57 - 03:08] Naturally, if a file can be recreated, we don't need to include it in source control. For example, this includes any build artifacts, dependencies, such as node modules, or debugging outputs.

[03:09 - 03:23] Better yet, having source control track files like this can cause git to become slow and make merge conflicts more frequent. To prevent files and directories from being tracked by git, we can create a file called dot git ignore.

[03:24 - 03:36] Dot git ignore is a new line separated list of regex values that tells git what to ignore. Create a dot git ignore file at the root of scroller.

[03:37 - 03:50] We'll add node modules to exclude any dependencies from git and our disk folder to exclude the final build from git also. First, we'll add all the files to git staging area.

[03:51 - 04:02] In the scroller directory, run the command git add minus a. This is a shortcut to add everything.

[04:03 - 04:16] Next, create a commit or snapshot of the stagecode by running git commit minus m with some comment. Minus m lets us inline a git commit comment straight into the terminal.

[04:17 - 04:30] Here, we'll just say my first commit. We'll set main to be the master branch for running git branch minus uppercase m main.

[04:31 - 04:49] Navigate to the scroller github page recreated and copy this git remote at origin line. This will tell git to push any code to the github page.

[04:50 - 05:09] Finally, to get the commit pushed to github, run the command git push minus u origin and then main, the name of our branch. In our github page refresh the screen and notice our code is now pushed up to github.

[05:10 - 05:29] [ Pause ]