Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Learn Git

You can set up global "git config" settings that apply to all git projects on your system. In this lesson, we review how the `./gitconfig` file works. We then add our own git config settings: username, email, editor, and git aliases.

There are many other git config commands that can be used, but this lesson shows you pattern behind them all so you can view and edit your own settings.

Practical Git: Configure global settings with git config

A reliable version control and source code tracking process is important for delivering apps with consistency and reliability. In this lesson, we will learn aspects of the Git Flow branching model which provide standards for developing and deploying apps with Git. We will walk through the methodologies of this well-known branching model, how to work with it from develop through to staging environments, and versioning your source code properly for production.

Use Git Flow as a Reliable Version Control Model

This lesson explores what git ignore files are and automating the creation of git ignore files.

The methods covered in this lesson for creating git ignore files are :

1. Manual Method
2. Using Github Site
3. using an IDE
4. using Gitignore.io

Create Automated .gitignore Files for Your Project

When you merge code in Git using a command line, it’s easy to miss merge conflicts. iTerm has a feature, named *triggers*, that may help.

Regular expression I’m using to match conflicts in Git merge results: `CONFLICT \([^)]*\)`.

Highlight Git Merge Conflict Messages with iTerm Triggers

You started working like mad on a dozens of different files and totally forgot to commit in between. Now it’s difficult to find a proper, meaningful commit message right? In this lesson we’re taking a look how you can individually commit just some of your files into the repository.
_Note: This only holds if you did not yet push your changes to the remote repository_


Only commit some of my currently modified files into the repository

In order to always have a good overview of what’s going on in our repository, we use `git log`. However, the build-in git log output format is not really suitable for everyday usage. In this lesson we will create a dedicated git alias `lg` which will printout a nicely formatted `git log` list.

The example used in this video: 

```
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --branches
```

But there are more available on the web, just search for it :)

Make my git log look pretty and readable

Gosh no, I just added all of these commits to master. They were thought to be peer reviewed first in a dedicated branch! No worries, in this lesson we’re going to see a couple of commands that will help you move your commits into a dedicated feature branch.

> Note: This only holds if you did not yet push your changes to the remote repository

Move some commits to a separate branch that I have accidentally committed to master

Usually when you develop on some feature, you create a dedicated branch that starts from your main development line, usually `master`. However, the longer you work on your feature branch, the bigger the final merge will be. In this lesson we’re going to take a look at how you can regularly update your feature branch with the latest changes by using `rebase`.

Update my feature branch with the latest changes from master

When you update your local feature branch using `git rebase`, you’re rewriting the history. As such, when trying to update your remote branch counterpart using `git pull` you will be rejected. In this lesson we’re going to have a look how to use the `--force` and `--force-with-lease` to force an update of the remote branch.

Push a rebased local branch by using `--force-with-lease`

It is a good practice to commit as often as possible while you work on your personal feature branch. That helps you trace your changes as well as to have a backup to jump back to in case something goes wrong terribly. However such git branches with dozens of commits (that may not make sense) are hard to merge and review. In this lesson we’re using an “interactive rebase” to adjust our git history.

Polish my git feature branch before merging or submitting for review

We work on our feature branch and commit a lot, also knowing we’ll have to do an interactive rebase to clean up our history once we’re done. Well, we could also automate that cleanup step to some degree, using Git’s autosquash feature. Let’s have a look.

Automate the cleanup of my feature branch with Git Autosquash

Often you have your feature branch you’ve been working on and once it’s ready, you just want it to merge into master as a single commit. You don’t care about all the single commit messages as they may not be relevant. There’s a nice “autosquash” feature in git which we’ll use in this lesson.

Squash all of my commits into a single one and merge into master

Did you make a typo in your last commit message? No problem, we can use the `git --amend` command to change it very easily.
_Note: This only holds if you did not yet push your changes to the remote repository_


Change the commit message of my last commit

You committed your work to the repository and just realized that you’ve forgotten to include some of the files. Let’s see how we can fix that by leveraging `git --amend` to include the missing files as well.
_Note: This only holds if you did not yet push your changes to the remote repository_


Add a file I’ve forgotten to add to my last commit

When you accidentally committed some changes to your branch you have various possibilities to “undo” that operation and add some more changes. One is to use `git amend` to change the commit message or add new files. But what we want to take out all of the committed changes again and maybe even split them into separate commits. Let’s see how we can achieve that.
_Note: This only holds if you did not yet push your changes to the remote repository_


Undo my last commit and split it into two separate ones

If you want to permanently remove  a commit from your branch we can use the `git reset` feature. Let’s have a look.

Wipe a commit from my local branch

If we pushed our changes already to the remote repository we have to pay attention to not change the git history  (using commands like rebase, reset, amend etc). Other collaborators of the same repository might already have pulled your changes, thus resulting into horrible, strange merge conflicts if we change the git history. There are some “safer commands” for undoing in such cases.

Undo a commit that has already been pushed to the remote repository

We all know this. You’re working on some new feature and you have lots of “work in progress”. Then an urgent issue comes in, you have to jump onto the master and apply a hotfix. In this lesson we will learn how to temporarily store your current changes s.t. you can switch the current branch and come back later to resume your work again.

Temporarily store some work in progress because I have to jump to another branch

In this lesson we'll start with an empty folder and initialize the project that will serve as the base to build up our own React boilerplate project. We'll also initialize a git repository and walk through checking the repo status, adding files, committing and we’ll take a look at the git log.

Initialize an npm Project and git Repository

In this lesson, we’ll create a new repository on GitHub, set the remote on our local repository and push our changes up to GitHub. We’ll add a readme, look at how our git status changes when we have changes that aren’t yet on the remote and we’ll see how running `npm init` again will update our `package.json` with new information.

Add a Project and Push Changes to GitHub with git

Redirection like `ls > out` only applies to a single line, so how do we control bash's input and output streams for blocks of commands? `exec` does just that -- it changes where stdout and stderr go for all commands that come after it. 

In this lesson, we'll use `exec` in a script to redirect all stdout and stderr to a log file. Our script will be a post-merge git hook, which runs after a git pull is performed. It'll check git's list of changed files and run `npm install` if package.json was changed. Because git operations are sometimes performed inside UI instead of the shell directly, it can be handy to capture any errors in a log file. 

Topics

Instructors

Content Type

Free or Pro