GitHub Essential Training

  1. The Modern Development Pipeline with GitHub

    • The basic GitHub Workflow: Every workflow starts with a master branch, and if you are going to do anything that is an extra to your site, like a bug-fix, or a new feature, then you would make a new branch for it. When you edit, create, or delete any files, you are making commits, which are the changes that Git tracks. Then when you have the changes you want, you can set up a pull request, to collaborate on the new design you made. Once you have recieved feedback on the design, make the neccessary changes, and put it on the master branch.
    • Designing your software delivery pipeline: There are a few things to consider when designing your workflow: Security concerns, Automated testing, code reviews, other GitHub features.
    • Tools for securing your workflow: To protect the master branch from direct changes made to it, you can turn the setting on in your GitHub Master branch. You can also use the Pull Request Reviews setting to make sure that before anyone merges anything into the master branch, they have to have a minimum number of approvals, like 1 or 2. Another level of protection is the option to decide who can merge pull requests into master. One last level of defense is to have a specific status check before they merge into master.
    • The role of CI: Continuous Integration (CI) is the process of automatically building and testing your software on a regular basis. It adheres to your team's quality standards, reduces content switching, improves consistency for testing, reduces bugs in production.
    • The role of CD: Continuous delivery is production ready with every commit, gives you the flexibility to release at any time. Continuous deployment takes it one step further:
    • The supercharged GitHub workflow: It is the basic workflow but with a lock on the master branch, and CI, and CD included.
    • Getting started with our first GitHub Learning Lab: To access the GitHub Learning Lab, you will need to navigate to the GitHub Learning Lab site, and sign up for it, then click on the courses tab in the navigation. Navigate to the course Continuous Integration with CircleCI.

  2. The Super Charged GitHub Flow in Action

    • Enable continuous integration: On your repository, you would go to Add Projects, type in name of your repository, and click Set-Up Project. Then scroll down to where you see Start Building. It will most likely fail, and that is ok, so we can do the next step.
    • Learn how to use CI with a configuration file: Now we can do a pull request to update our configuration file. Navigate to the pull request page and click on Create Pull Request.
    • Specify the Docker image: You can click on Files Changed and replace the REPLACE-ME-WITH-DOCKER-IMAGE, with this text: githubtraining/ci-custom:latest.
    • Merge pull request: Now that you have done this, you can now click Merge Pull Request. Once merged, we are also given the option to delete this branch.
    • Add automated builds: Now you can add a bundle exec jekyll build, and replace the placeholder text in the Files changed tab.
    • Add branch protections: You will be asked to add protections to the Master branch, along with other protections, like who can merge changes and pull requests to master.
    • Add changes based on a review: The files wil be ready as soon as you fix any typos or anything else on the files the bot says you should fix.
    • Add a CI unit test: Add a new HTML unit test. To do that, you now have to replace some placeholder text with bundle exec htmlproofer ./_site --check-html.
    • Fix broken build and merge: There is a broken link that you have to fix, and once you do, it will be ready to merge.
    • Add CD to your pipeline: You would need to navigate to the settings tab, and under GitHub pages, select source master branch.

  3. Understanding How Git Works

    • Using Git locally: If you have Git installed on your computer, you can use it locally by using the command line, and typing in the commands to have git track your files.
    • The anatomy of a commit: Every change you do, which is in your wrking directory, is assigned a SHA-1 value which is a 40 character long ID. After you are done making your changes, using the git add (file_name = .) will put your changes on the staging directory. Then when you commit the changes, it is given its own SHA-1 value, and an author, along with a commit message.
    • Why commit relationships matter: The commits are based off of each other, as in the most recent commits parent is the commit before it, and its parent the one before, and so on until you reach the first commit ever.
    • Understanding branches: Here is a site that helps to understand branches: Visualizing Git.
    • Where is your HEAD?: HEAD is where you are positioned in the Git repository.
    • Where does Git store all of this information?: It stores it all in the .git file.
    • Working with remote traking branches: To view all of your branches, remotely and locally, use git branch --all, and to switch branches, git checkout (branch_name).
    • Viewing local history: git log allows you to view the commits you have made locally. This site shows all the command options that you could add to it.
    • Using Git aliases: Using a Git alias is helpful for when you type the same command multiple times daily. There are three ways to creating an alias: the first is git config --system, but it affects everyone on the system. Another way is git config --global, which affects a single user, but also all of their repositories. git config --local, which affects only one user's current repository. After whichever of the above commands you choose, put alias.(alias) "command to give"
    • Help me find that one commit: git bisect start is how you would start to look for bad commits. To find what commits are bad, you can type git bisect bad (commit#) as your end point, then you do a git bisect good (commit#) as your starting point. Once you have found the bad commits, you can use git bisect reset to cancel the bisecting.
    • Reverting changes with Git: To revert changes on a commit, type git revert (commit#), and it will make a new commit that reverts that old commits change, without removing it from the commit history.
    • Crafting atomic commits with Git: To make atomic commits with Git, add any changes you have made into the staging tree using this code: git add -p. The -p will allow you to seperate any changes that are in one commit. To do that, type ?, and Git will ask if you want to keep any of your changes in the staging tree, and it will also bring up a list of options that you could type.
    • Viewing local changes: To view local changes from working directory and staging directory, use git diff, and to view the staging directory and the commits repository, use git diff --staged, and to view changes from working to the commits repositories, use git diff HEAD.

  4. Get Out of Anything with Git

    • Rewriting history with Git: Here are some commands that can rewrite the history of your commits.
      revert: Generally safe to use with GitHub since it creates a new commit
commit --amend: Only use on local commits
reset: Only use on local commits
cherry-pick: Only use on local commits
rebase: Only use on local commits

    • Oops, I messed up my last commit: The commit --amend can only change the most recent commit you have done.
    • Everything is broken, help me reset history: The reset command can reset everything back to a certain commit that you have specified. It also has three modes
    • Reset back to staging area: git reset --soft (commit#) resets everything back to the staging tree.
    • Reset back to the working directory: git reset --mixed(optional) (commit#)
    • Reset to the trash: git reset --hard (commit#), completely deletes the commits up to the one you specified, on all three of the trees.
    • I just want that one commit: If you have deleted the commits you don't want, but then realize that there was a change that you wanted in the deleted commits, yopu can use git reflog, and it will show where HEAD has been. Once you have found the commit that you want, you can type git cherry-pick (commit#).
    • I need to restructure my commit history: Rebase can reorganize your commits from multiple branches onto one line.
    • Rebase in action: In order to start a rebase, you would need to checkout to the branch you want to rebase, then type git rebase -i (branch_to-rebase-onto). Once you have rebased your files, you can now merge them into your master branch.

  5. Resolving Merge Conflicts

    • What is a merge conflict and how do they happen: A merge conflict is when two conflicting changes, are merged into one branch, and they disagree with each other.
    • Resolving a merge conflict: To resolve a merge conflict, open up the file with the coflict, and the content will have two copies of the same content, but with both sets of changes seperated by these conflict markers: (<<<<<<< HEAD), version 1, (========), version 2, (>>>>>>>> file_name) (remember to delete the markers once you are done). Now you will have to choose which version to keep, combine them, or just completely redo the changes.
    • Make a local change and create the pull request: Navigate to the GitHub Learning Lab GitHub Learning Lab, and locate the Managing merge conflicts. Now just make a simple change, then make a pull request.
    • Merge the pull request locally: To merge a pull request with your computer's files, first make sure you are on your master branch, then type git merge branch_name. Now type git push.
    • Resolve a simple conflict and merge: To resolve a conflict, just open up the file in question, and choose the version that you would like to keep (MAKE SURE TO REMOVE THE MERGE CONFLICT MARKERS). Once done, you can merge it in to the branch.
    • Create your own conflict: Creating a conflict is easy, just make some changes in a file on master, commit them, then push them up to GitHub, yet then make some more changes to same file but in different branch, commit those, then push them up. The second set of changes will create a new branch unless the branch is already there. Now merge the second set of changes from that branch to master. It will pop up a merge conflict that you will have to solve.
    • Resolve your own conflict: Go ahead and choose which set of changes you would want to keep, and save them and push them up to GitHub.
    • Resolve advanced conflicts and merge: Resolving and merging advanced conficts is not as hard as you think. Simply do the same thing for one conflict, but this time it is more than one file, and possibly more than one set of conflicting changes.

  6. Customizing Your Workflows

    • Merge strategies: There are two types of merges: Fast-forward, and recursive. A fast-forward merge is when there are no commits on base branch when you merge in a branch. A recursive merge is when there are commits on the base branch, and it creates a merge commit. If you only want to do fast-forward merges, use the git rebase command. If you only want the recursive merge then you can do git merge --no-ff.
    • The perils of long-running branches: The difference between the git-flow and the GitHub flow is the number of long-lived branches. Long-lived branches, often contain part of the code, hard to know which one to use, often require helper scripts. Don't have a lot of long-lived branches because it will get confusing.
    • Fine tuning the GitHub flow: Some people say that the GitHub workflow is too simple, and needs to give user's more control. There is kind of a Develop branch layer that is connected to master, and is where everyone puts all of there code and merges and everything else too.
    • Considerations for workflow design: Here are a couple of things that you could ask your team or group about how the workflow for their Gitub project should work.
      1. Which branching strategy will you use?
2. Which branch will become the master branch?
3. How will you protect your code?
4. Will you use naming conventions for your branches?
5. How will you use labels and assignees?
6. How will you indicate sign-off on pull requests?
7. How will you tech your workflow to your team?
8. What integrations will be used?
9. If users have questions about Git, GitHub, or their workflow, who do they ask?

    • Pitfalls of a non-innersource culture: Here are some problems related to this typ of stuff: Lost development time, bugs, delays, security, faulty communication, not knowing who to talk to, nd a bunch more things like that.
    • Adopting an innersource culture: Here are some advantages to the innersource culture: Open collaboration encourages more contributions, developers, don't always have to start from scratch, Transpareant decision-making builds process, trust, and alignment, higher quality development, and better documentation.