Understanding Git

Taken from this tutorial by Fireship: https://www.youtube.com/watch?v=HkdAHXoRtos

Git is a version control system for managing your files

Initialise an empty Git repository in our current working directory:

git init

Any files in this directory will be added to the changes list.

You should then create a .gitignore file

touch .gitignore

You should keep private things here, like sensitive API keys. You can find default settings for this file

We next want to commit our changes, which is to send our local files into the Git repository. We need to stage the files that we want included in this commit.

git add .

Using a period here will stage all of the files. If you want to unstage all files, you can do the following

git reset .

After we have staged our files using the git add . command, we will then run git commit with the m flag with a descriptive message about what we changed in our code:

git commit -m "enter text here"

Up until this point, we have been working on the master branch, which is essentially the main trunk on the tree that contains the source code that you are releasing and delivering to your customers / project / documentation.

If you want to fix a big, or experiment with a new feature, you can create a new branch based on your most recent commit, and go and fix the bug on the separate branch, then merge it back into the master branch once it’s ready. This means we can have multiple developers working on the same code base working on their own branches without stepping on each other’s toes.

You can see all the current branches on your code base but running:

git branch

You can switch between branches in Git by running the checkout command:

git checkout

You can create a new branch by adding the b flag and giving it a name feature:

git checkout -b feature

Now any code we write in here will be isolated to this branch

If you are working on something that is half-finished or experimental, and want to save all of your current stages without committing them before you switch to another branch, you can use:

git stash -u

When you want to get back to work on this half-finished piece of work, you can run the following which will apply those changes to your current working directory:

git stash pop

To merge the changes made in the feature branch, we switch to the master branch and run the git merge command followed by the name of the branch we want to :

git merge feature

This will merge the latest commit from the feature into the master. This then results in the commit ID of the feature matching the commit ID of the master.

Merging branches is where most problems occur. If you are working on the feature and the master has changes, publishing the feature can lead to merge conflicts.

In order to prevent this, you will want to merge the master back into the feature so that you have the latest code in the feature before you then merge the feature back into the master.

If you have many commits in the feature, and you don’t want to have all of these commits included in the merge to the master, you can use the squash flag:

git merge feature --squash

This will squash these into a single commit when you do your merge. This will keep the change history nice and concise on the master branch, but this still preserves all of the original commits on the feature branch itself.

When you merge with the squash flag, it won’t change the HEAD commit on the master branch, so you will need to add an additional commit on your own that says something like “merged in feature branch”.

So far we have only been making these changes locally, now let’s push these changes remotely. After creating a GitHub repository, we need to connect our local code to the remote repository:

git remote add origin https://github.com/username/repository-name.git

Then we will push the files to the remote repository:

git push -u origin master