GIT: Advanced commands

In order to work with a remote repository, we need somewhere to host it.  GitHub is the ideal choice for this course because it is one of the most popular places to store code, both privately and publicly.  There are other choices available for sure, such as BitBucket, GitLab, and Azure DevOps (among others).  If you're familiar with using one of those, then by all means keep using it!  All of the major providers will have the ability to do everything that we are covering in this course (it just may look slightly different at the other providers).  

Speaking of looking differently, before diving in, note that this video was recorded a couple of years ago.  I've created so many accounts at GitHub at this point that I don't think it's reasonable to do another account to make a video.  For that reason, I'm trusting that you will have the skills to make your account at GitHub using your email and a password.  

A couple of things are different in this video from how they are now.  For example, GitHub no longer requires a subscription to have private repositories!  So you will see a section where I talk about that in the video - just know that you do not need to sign up to pay for any subscription at GitHub and you will still be able to do free repositories and all the other things you would want to do in this course and beyond without paying for anything.

I would also recommend enabling Multi-factor authentication at GitHub using a generator like the GitHub authenticator, the Microsoft authenticator, or any other authenticator (it gives you a code on your phone after you add the account).

In this video, we walk through setting up an account at GitHub.  In some ways I feel silly even putting a video like this out there.  Hopefully getting an account at a website is not something you will struggle with.  So if you've already got an account at GitHub and/or you know how to do this, you wouldn't really need to watch this video. 

In other ways, there are people who like to see everything from the ground up.  For those of you who are like me, this walk through will be nice background noise while you work through getting an account set up at GitHub.

In the end, to move forward with this course, the main goal here is that you have a working account at GitHub where you can create Remote repositories.  

One final note: In this video I mention getting an account at BitBucket as something else we might do in this course.  To be clear, this course will not have any videos or information about using BitBucket.  However, you are perfectly able to use BitBucket if you choose as everything we do here can be done against BitBucket.    The same thing goes for GitLab, Azure DevOps, or another provider.  However, this course will only show interactions with GitHub.

In this video, we take a look at getting our first repository setup at GitHub.  If this is not new to you, then you may feel free to just skip over this lecture. If you've never done this before, then I hope you will find the information in this video useful.  

When working with our files/code we need to have a remote repository so that the data is not just stored on our machine.  Could we get by without a central location? Of course, but only if we are the only one using the files, and we'd be losing out on a lot of useful things that a remote repository offers.  For example, putting our code on a remote repository gives us the chance to restore to any machine, at any time.  Not only that, be we can easily make changes on one or more machines at different times or the same time, and then we can make sure that no changes are lost using branching and merging.

The REMOTE repository will be the centralized location, and we'll clone and/or create repositories to work with on our LOCAL machines.  We'll set up our LOCAL repositories so that they track to REMOTE.  This is how we'll be able to move changes from REMOTE to LOCAL and LOCAL to REMOTE.  

For our course, we'll need a central repository stored at GitHub, and this video shows how we go about getting it setup.  If you can't quite follow along the first time, don't worry: The activity that follows will get us setup for our course. 

In this video, I show how to get VSCode installed on your windows machine.  Using VS Code will make the ability to work with files and the terminal for commands seamless.

You don't need this tool to complete the course, but as a Windows developer you might find that working with PowerShell/Bash/command line, etc can be nicely encompassed in the Windows Terminal.  Install if you want an additional tool that can give you a nice place to run CLI commands from various command line environments.  Feel free to mark this complete and skip if you want. The tool will not be used in the rest of the course (GIT Bash will be used, which can be accessed from VSCode, the windows terminal, or directly).

This video shows how to install GIT on your machine. If your version is newer, that is just fine.  You should select the newest (latest) version that is available at the time you are taking this course.

Note that this video is taken from a series I made to get a developer box set up.  At the end, the video mentions a next part about validating GIT. Part two is not included here because that is just checking your version, creating a repo, setting credentials, and using add and commit, and we do that through the rest of this course, so you don't need that video as all of it is covered in the next few videos.

Topics Covered
- GIT Download (git-scm dot com/downloads) [Windows]
- Install location
- Options for installation
    - Open in Git Bash
    - Use Visual Studio Code as Git's default editor
    - Override to `main` as the default branch
    - Git from the command line
    - Use bundled OpenSSH
    - Use the OpenSSL library
    - Checkout Windows-style, commit Unix-style line endings
    - Use default terminal
    - Fast-Forward or merge (default)
    - GIT Credential Manager
    - No experimental support

In this video, we go about getting GIT setup on our machines.  This is the "Ubuntu Linux" version.  Without getting GIT on our machine, we won't be able to run the commands and work with the repositories as shown in the rest of the course.

Without getting GIT on our machine, we won't be able to run the commands and work with the repositories as shown in the rest of the course.  Unfortunately, at the moment I have no access to a MAC to create the installation video.  Please use the provided link in the article to go to the official download page, and follow any instructions/prompts to get GIT on your MAC setup.

Although GIT BASH comes with VIM built-in, hitting "i" to insert and "escape colon w q" to write and quit gets pretty old, pretty fast, especially for a non-unix guy like me.

Therefore, we're going to use VSCode as an additional tool to help us when working with GIT on our machines.  This is a powerful and free tool, and is only one option of many that are available to you.  If you can't stand Microsoft or want to go a different route, you are welcome to do so, but just know that you are on your own for getting the exact syntax for setting up a tool other than VSCode (stack overflow would most likely have the answers you need to use your favorite tool).

In this video, we create the global settings necessary to set our default editor.

NOTE: If you set up visual studio code before you set up GIT, you may have seen "Use VSCode as GIT's default editor".  If you selected that option, then you do not need to do anything extra to use code as your editor.

If you can type the command:
`git config --global -e` and it opens Visual Studio Code to edit your config file, then you already have this set up correctly.

When looking at the differences in commits for GIT, we can easily do this by running the command

[git diff <commit1> <commit2>]

or

[git diff --cached]

among others.

However, using the default diff view and seeing our changes print out in the command terminal is not really an ideal way to review the changes and see the exact differences.

Even though we won't be diving into the diff command or using the difftool much (if at all) in this course, we're setting everything else up, so we may as well get the difftool setup as well.

This videos shows how to configure the global config for a default difftool set to Visual Studio Code

In addition to using VSCode for the default difftool, I wanted to show how you can turn the difftool prompt off.  If there are a ton of files to go through when reviewing differences, having to select "Y" for reviewing for each one could be rather annoying.  Therefore, we can shut off the difftool prompt so that it won't ask for each file with differences.

Whenever we hit a merge conflict, we want to have a nice tool to perform conflict resolution.  If you don't already have something in place on your machine, this video will walk through getting VSCode setup as the default mergetool.  Having set VSCode as your default mergetool will make life a lot easier when merge conflicts arise.

Perhaps you already have some projects and you want to get them into source control.  If that is the case, then you will want to see how this is done.

After this video, there is an activity that lets you take a zip file for a project called "default web" that has a very simple web solution in it.

Additionally, you could just go to my repository directly [https://github.com/majorguidancesolutions/defaultweb_activity] and either

• download the code directly
• or clone the repository locally, then delete the .git folder and start from scratch
• or fork the repository to your own account at GitHub

To be honest, you really don't need any of this.  Also, if you have your own code, you can just use that.  What we need to get through this course is nothing more than a repository where we can store any text file and just work against it.  So if you want to just have one text file in a folder and create a repository and push it out to GitHub, you would be able to do everything we're doing in this course with that minimal implementation.

I'm using a tool called "GitViz" to do some demonstrations throughout the course.  I put together a video on how to get it up and running if you want to have it on your machine.  I believe there is a release version in the repo but if you have VS and want to build the latest version, you should be able to do that.

The link to the repo is: https://github.com/Readify/GitViz

Please review the ariticle for this lecture to get more information about the repository that I am using in this course.

Please review the attached article for information related to the website I used in some of the demos.

It may be the case that you have not worked with GIT for some time, that you aren't automatically updating, and/or you just need to get the latest version manually.  In this video, you'll see how to quickly run a command to update GIT from the command line.

I understand that this is an ADVANCED Course an you may not need this section.  If you are beyond the basic level and don't need to review the basics of how GIT works, please just mark this section completed and move forward. 

Remember that not everyone taking the course will likely be as advanced as you might be, and therefore they might need this section, or enjoy the review, even if you don't.  

I understand that this you may not need this section.  Remember that not everyone taking the course will likely be as advanced as you might be, and therefore they might need this section, or enjoy the review, even if you don't need it so I put this out to make sure that all students get the best experience possible.

Thanks for your understanding, and I hope you enjoy this section if you need it, or just move on if you are ready!

In this first part of the three-part series, we discuss what source control is, a bit of history about source control, and what it means to use a local and/or remote repositories.

In this second video, we discuss the process of moving changes through the process of making changes to tracked or untracked files, adding to the index (staging), and committing to the source of truth (history) on the local repository.

In this third part of the video we talk about how to move changes to the remote using a remote upstream tracking branch and essentially how the GIT flow works for a general lifecycle of file changes.

In this video, we take our first look at the ability to amend a commit.  This is accomplished with the command [git commit --amend]  and then an appropriate message either with the -m flag or through the editor.

We'll take a quick look at viewing our history with the git log and show how we can use the amend feature to change the details of the last commit.  The important thing to remember is that the original commit is orphaned and a new commit is created with the new details, essentially 'replacing' the old commit.  The reason this is important is because anytime we change our history like this, we need to be certain that we are not modifying a public commit change.  

For example, if we were working against master and changed the commit history with an amend (or rebase, reset, or another history-altering operation), we would be putting others at risk.  If we take away commit a1b2c3 and developer 2 is reliant on a1b2c3 to be in the commit history as a parent to their changes or as part of the history leading up to the parent of their changes, then they would have a very hard time getting their changes in place as they would potentially be unable to find a common ancestor to merge their changes into master.  

So, anytime we are rewriting history, including with an amend operation, we need to be certain that it is not on a published public branch and/or that no other team members are currently dependent on the commit where we are changing history.

Also in this video, at the time of the recording I had a personal issue with my setup - in that I wasn't waiting for code to complete to complete the commit.  I show how this happens and how it causes me to fail to amend the commit message as I wanted to.  I also show how setting the -w flag on the default editor is a remedy to this issue.  Hopefully you don't have that issue, but if you do, now you know how to solve it.

In this video, we take the time to work with the [git commit --amend] command one more time.  

This is just another way to practice using the command, as we can now realize that we can do whatever we want on an amend.  We could make any changes we want - add files, delete file, remove comments, fix bugs, etc. 

While the ability to amend is very powerful, once again we just need to remember that we should not be making this type of change on a published public branch.  If something is terribly wrong in the case where a branch is already published and public, other options exist, such as revert or simply just making the changes and pushing as a new commit to follow the bad one.  We could always then just tag the bad commit so everyone would know there is an issue and not to reset back to this point.

In this video, we take our first look at the reflog.  

As I've been showing different aspects of the repository during our activities, I've been using the 'GitViz' tool.  The thing about the GitViz tool is that it has to be getting its information from somewhere as well, right?  When we can see commits that are not reachable but still listed, there has to therefore also be a way to see this in the terminal.  This is where [git reflog] comes into play.

We start off by looking the log and noticing that only the reachable history is shown in the log, and then diving into the reflog to see the commits that are currently unreachable.

We also note that reflog actually tracks things like moving from one branch to another, and then other things like commits, merges, resets, etc.  All of the history refs contain the same syntax HEAD@{n} where n is a number from 0 - n.  The most recent item is at index 0.

We notice that we can then use the reflog to be able to determine a commit id and checkout the commit based on what we can see in the reflog.

The nice thing about the reflog is we can name a specific index, or we can start to use time differences, such as HEAD@{4.days.ago} to get the reflog starting from a specific point in history and working backwards in time.  

In this video, we continue our examination of the reflog.  

We start out by looking at ways we can see the differences between two different entries in the reflog.  Essentially, it's nothing different than using the direct commit id, but now we can use the reflog ids.  For example, [git diff HEAD@{2} HEAD@{7}], etc.

We then move into using timespans to see how we can compare the repository for something like [git diff HEAD@{1.min.ago} HEAD@{4.months.ago}].

Next, we note that we can use the reflog to expire unreachable commits to be immediately collected with the garbage collector.

Finally we note that anything we can do with log we can do with reflog, but we see that most of it either does no good or gives an error if we try to use it.

I was so excited when I saw this feature at GitHub.  So excited that I decided that every time I merge, I would use the Squash & Merge option, because having only one commit seems to look a lot nicer than having lots of commits.  In same ways, it very much is the case.

However, the real problem comes into play when you do this because you are writing a public commit history, and it will NOT line up with your branch where the original commits take place.  Because of this, it can be dangerous to use a squash and merge without deleting the feature branch when done.  Note that I said it can be dangerous, and I did not say that it is impossible to keep using a feature branch, but I will say you should have a very good reason to keep using the same branch after squash and merge.

In this video, we continue working with squashing and merging with GitHub, where we now perform the cleanup so that the commits in our local history won't keep popping up as needing to be merged during each push/pull request operation.

This reiterates the point that it is a very good practice to delete the local branch as well as the branch at GitHub after performing a squash and merge.

After seeing the cleanup, we can see how nice the history looks and we know that we don't have to worry about commits that are no longer part of the history getting in our way or showing up again in an unwanted manner.

In this video, we're going to take a look at what it would look like if we do the squash and merge at GitHub but fail to cleanup.  It would not be impossible to keep working with this branch in the future, however it would require that we then 're-commit' the original commits that were committed before the squash and merge.

We see that GitHub is smart enough to only show the file that has been changed, even if there are multiple commits in one branch of the history that no longer exist on the second branch.

In this video, we are going to go over setting up aliases.  Aliases are great, because they give us the chance to condense longer commands into a short, easy-to-remember command.  Additionally, we can put commands that might be harder to remember into a simple command (for example, we could create an alias for git pull --rebase as "gpr" or git fetch --prune as "gfp".  

In our course, we've seen a couple of commands that we hit over and over again - 

[git oneline --graph]

and 

[git reflog expire --expire-unreachable=now --all]

and

[git gc --prune=now]

In this video, we'll set aliases into the global config file for each of these, so that we can easily run these commands throughout the rest of the course.

A couple of quick things to note about aliases, however.

1. Because they are created in the global config on your user profile, they do not exist on another machine without being re-configured
2. Putting the commands into an alias may lend itself to the fact that since we don't type these commands over and over again, we may actually forget the commands.

Finally, as mentioned toward the end of the video, due to the local nature of the aliases, we may consider adding a file to a repo somewhere that is just for our aliases, which would make it easy to restore on another machine in the future.

When we have multiple developers working on a repo, we need to fetch often to get changes.  Also, as a team member, we've probably created a bunch of local branches that we've used during development.

Perhaps after we perform the commit, we delete the branch at GitHub, but never take the time to do any cleanup in our local repository.  

If we set our command for fetch to prune, we can be assured that each time we do a pull, all of the remote references that no longer have a valid branch at GitHub will be removed from our local repo.

To make it so that our system always prunes on fetch, we can add a simple entry to the global config.

As we start working with the repo, there are times we just need to get files that we had added to index back out of the added status and give us a chance to reframe what we'd like to add for the commit, or undo the changes with a hard reset or rm/clean operation.

We can see with reset that we can also go back to the previous commit by entering the previous commit id and still not lose our changes.  This is great, because it means we don't have to worry about losing our changes, even if we "rollback" to a previous version of the repository - as long as we do a soft reset.

In this video, we perform our first "hard" reset.  The major difference between a soft and a hard reset is that with the hard reset, we move the files back to the state they were in before we did anything to them.  Therefore, we can actually see how this type of operation is really useful if we start going down a tangent and want to throw everything away and start over.

The caveat here is that the untracked files will still just hang around.  We could just remove the untracked files that we had added, or we can run a clean operation to get our local working directly back to the correct state that it should be as of the last commit.

We use a couple of options flags here to make sure that we don't ignore files that are in the .gitIgnore and we hit all of the directories and subdirectories.  Also, of most critical importance is the ability to use the -i flag on the clean activity so that we can have an 'opt-out' option to make sure we don't wipe out files/folders that we don't want to lose.

In this video, we take our final look at using the reset command by performing a hard reset back to a commit.  

The great thing about performing a reset is that we can go back in time to the state of the repository at the time of the reset.  As we saw in the soft reset video, this is just to the previous commit, but as we see in this video, we can go back as far as we want.

If we needed to make a change, then, we could reset back to the commit and then checkout a branch from that point.

However, we once again need to be really careful about what we are doing here, because if this is done against a public branch and we change the history by resetting and then commiting a new line and merging that into master, we could really cause a lot of problems for others that are trying to work with the repository, depending on how we merge it back.

In the video, we get to see how we could go back to a previous commit, checkout a branch, make a change, and then bring that into our master.  Certainly there are other ways this could have been done, but this gives us a decent look at how we could work with reset to help us fix a broken repo.

There will be times when something is just not right with the latest commit.  Often, this won't be discovered until we push out to a new environment and someone else tests and determines there is a problem.  By now, our changes are in the master branch and we don't want to change a publicly published commit history.

We could just checkout a new branch, make all the 'undo' changes, and then push, but GIT has a built-in command that lets us directly undo everything that was done in the last commit.  This is really cool, because there is far less of a chance that we will miss something small that might get missed with a manual operation to revert to the previous version.

In the next few videos, we're going to learn about one of the coolest operations that we can do with GIT - which is to perform a rebase.  There is nothing cooler than seeing your commit history move from one parent to another, and there is very little that can invokes as much fear in users as this can.

For this video, we just take a look at a simple demonstration to see how rebasing should work, and then we'll get a chance to apply what we've learned in the next few videos.

In this video, we will simulate two developers interacting with the repository, so we can see what it looks like to need to rebase our history after another developer had pushed a change into master.

Since we are simulating a couple of developers, this video actually gets too long and we don't get to do the rebasing in it just yet, so we'll get a chance to see that in the next video.

In this video, we continue our first rebasing activity. In order to do the operation, we first need to get master up to date and then we switch to the branch we want to rebase, and rebase master.

The GitViz tool gives us a nice view that lets us see how the rebase takes place, and of most important note is that the commit ids are changed during a rebase.  This is again why it is so critical to not do a rebase operation against a publicly published branch.

The video goes on to show how each developer can continue to rebase the changes as each make changes in the repository.

We finish up by expiring and running the garbage collector so that unreachable commits are no longer available.

In this activity, we're going to rework the first rebase activity, but this time we're going to see it with a conflict.

Of course when a conflict exists, the only real difference is that we'll need to resolve the merge in order to perform the rebase.

Once the rebase starts and the conflict exists, we get a very long message about what to do for continue or abort the rebase.  Also note that we get to see how many conflicts we need to resolve.

If we wanted to abort, we could easily do so by typing [git rebase --abort].  However, we're going to resolve so we use our mergetool.

After the conflict is resolved, we type [git rebase --continue] to make the rebase happen, and we note the different commit id that once again is created at the end of the rebase operation.

Another thing to note is that it's very clear at this point we are keeping a very nice, very linear commit tree.  By performing the rebase, we don't get the various branches going off in different directions from a commit and then needing to come together again with a merge.  Instead, we "start" each change after the other has already been committed.

In this video, we are going to see what it takes to squash our commit history locally using what's called an "interactive rebase."

This is probably one of the most fun operations we'll do, because we can immediately see how useful it would be to keep our history very clean.  Although our feature may have many commits, when we go to master we really just need the one commit that contains all of our changes.  So if we have multiple commits and want to condense, we just do a 'squash' operation via the interactive rebase.

[git rebase -i HEAD~n]   where 'n' is a number of commits to squash together

Once again, we make note that we're going to squash a number of commits into a completely new commit, which means this is rewriting history.  We do have to interact, picking the first commit, and then squashing the rest.  We then see that we get to put a commit message in place -> but all four commit messages are retained in the commit description - which is very nice!

To complete the operation we perform a pull request out at GitHub, where we also do a merge with rebase. Because we did do the rebase on the pull request, we again need to just clean up our local branch.  This time, for sure, since we are trying to keep everything linear, we definitely want to delete the branch so that we get rid of the commit that is no longer needed on the local branch that is already in master.

Cherry picking is probably one of the more 'scary' operations about GIT -> but it shouldn't be.  There are just a few things to remember about performing a cherry-picking operation.

1) You are going to get all of the history up to the commit you are picking by the nature of the game.  

2) If all you want is one part of the commit, you should do a cherry-pick operation with a -p [patch] flag, so that you can choose the correct hunks that you want to keep

3) In the end, you'll have brought the changes up to the commit you are picking into the branch you are picking to.

In the video, we setup our cherry-pick into a new branch and have to resolve a conflict.  Just like with rebasing, we see that the command lets us know we are in the middle of a cherry-picking operation.  Once again, at any point we could get out by using the --abort flag [git cherry-pick --abort].  To finish, we can just commit the resolved merge.

We then finish up with a merge with rebase, which means we'll need to wipe out the branches after to avoid having history conflicts.

When I first started with GIT, one of the things I wanted to learn more than anything else was stashing.  This is because I came from a TFS background, where we would do what is called "shelve" changes.  In essence, the stash is a lot like a shelveset, however, the advantages are real in GIT - for example, I can repeatedly apply a stash across any branches.

In reality, I've found less and less use for stash.  The reason for this is simple.  It is easy and inexpensive to create branches in GIT.  Therefore, for 90% of what we are doing, if the first thought is 'stash' it, the next thought should be 'why not just branch and commit and then go back to the original branch which would be back to the original state of the original branch, AND our changes would be easy to find and apply at anytime via a merge or pick with patch.

One useful thing I have found with stashing in the C#.Net world is to stash local web.config changes so that I can easily re-apply my database connection string for my local database - which I never want to commit to a public repository that should be pointed at Test or another common environment.

In this video, we start looking at stash, and see what it means to use git stash list, git stash save, git stash pop, and git stash apply.

In this video, we continue looking into how we might use git stash to work with changes across branches that we don't want to commit or that we want to re-apply over and over again.

We then look at how to cleanup our stash by individual stash indexes, as well as the full stash clear.

Another thing that is interesting is we can also checkout a new branch based on what is in stash (but note that this will REMOVE the stash item, so if it's something that needs to be persistent the stash would need to be re-created after checking out the branch from stash.

In this video, we take a look at tagging our commits.  Tags are awesome, especially when we realize that creating a tag essentially creates a release at GitHub that can easily be downloaded or checked out [just like checking out a commit, we can checkout by tag].

There are two types of tags that we need to be aware of - lightweight and annotated.  A good common rule-of-thumb is that if the tag is local to you, you can use a lightweight tag.  If the tag is going to be public, you should probably make an annotated tag, because it has nice information about who, when, etc, in the object.

We take a look at how to both push and delete tags from the remote repository, and we also take a look at how we can search all of our tags by some wildcard searching.  We also look at how we can delete tags from our local repository.

Finally, there is a setting we can put into our global config for making sure that whenever we push, we also push any tags using

git config --global push.followTags true

Congratulations! You made it to the end of the course!  Not everyone can say that so you should be very proud of yourself.

In this course, we covered a lot of the more advanced GIT commands, including:

• git commit --amend
• git reflog
• squashing and merging at GitHub
• git config --global alias.x
• git reset
• git reset --hard
• git clean
• git revert
• git rebase
• git cherry-pick
• git stash
• git tag

Although this course got us to the level of "very good" with GIT, it will take practice and real-world experience to be an expert.  That being said, I do hope that this course has positioned you to be the person on your team that everyone turns to when stuff goes wrong.

For next steps, you can continue to work with these commands in more detail, review the documentation online and keep growing your skills with GIT.  Additionally, there are more advanced commands that we did not cover in the course and we are certainly going to need to keep working with GIT to keep our skills sharp.

Once again, thank you for the chance to be a part of your journey, and I wish you all the best in the future!