Angular 4: Deploy to gh-pages (part 4)

Presuming: you have an Angular 2 or 4 project ready to deploy to gh-pages, and that you’ve created a github repo connected to your local directory and git inited it. Also you need to have installed and be using angular-cli. If not look at this post.

Angular 4 projects can be deployed on gh-pages by first installing the npm package angular-cli-ghpages,

$ sudo npm i -g angular-cli-ghpages

The previous command is run in your local master branch. There is no need to create a local gh-pages branch or in fact a remote one in your repository. First create your dist folder and set the base-href with,

$ ng build --prod --base-href https://<USERNAME><REPONAME>/

Do not forget the trailing forward slash at the end.

Then sent this to your remote gh-pages branch, which does not need to be previously created.

$ sudo angular-cli-ghpages --branch gh-pages

This is also run in your local master branch. Running this commands as deparately as above did not work for me, I had to create a script called ‘deploy’ which I placed at the end of the package.json “scripts” object, like this,

"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e",
"deploy": "ng build --prod --base-href && angular-cli-ghpages --branch gh-pages"

Then run this script with,

$ sudo npm run deploy

Then navigate to,


The following blog post from may be useful.

GIT Notes: Remote Repositories

GIT Succinctly – free eBook from Synfusion

    Chapter 6 Remote Repositories

Manage connections to other repositories, and list them with,

$ git remote

To get more information about remote repos,

$ git remote -v

Create a new connection to a remote repository,

$ git remote add <user-name> <path-to-repo>

Now you can reach that repo with user-name instead of typing it all out.
Git accepts protocols, file://, ssh://, http//, and git://

$ git remote add <user-name> ssh://<user-name>/<repo-name>.git

Repo can be found at,
Delete a remote connection,

$ git remote rm <repo-name>

Remote branches represent a branch is someone else’s repository.
fetching, the act of downloading branches from another repository.

$ git fetch <repo> <branch>

Omit branch if you want all branches in a repository.
View downloaded branches with,

$ git branch -r

Remote branches are prefixed with ‘origin’. You can look at their history with,

$ git checkout

Remote branches behave like read-only branches until you integrate them into your local repository.
Display new updates from ‘origin/master’ not your local ‘master’, like this,

$ git log master..origin/master

You can checkout remote branches but this will put you in a detached HEAD state, and without a branch changes will be lost, unless you create a new local branch tip to reference them.

Incorporate changes from origin/master into a local branch,

$ git checkout <mybranch>
$ git fetch origin
$ git merge origin/master

This results in a “3-way” merge. Your master has merged with origin/master and that then merges with your branch. This will produce many meaningless merge commits.
This can be overcome with rebasing,

$ git checkout <mybranch>
$ git fetch origin
$ git rebase origin/master

‘pull’ is the ‘fetch/merge’ sequence combined.
Fetch the origin’s master branch and merge it into the current branch.

$ git pull origin/master

That will merge, but if you’d prefer to rebase use the ‘–rebase’ flag, which I think would be used like this,

$ git pull --rebase origin/master (not certain that’s where the flag goes in this command)

Send local branch to a remote repository,

$ git push <remote> <branch>

This creates a local branch on the remote repository. (So a local branch can appear on a remote repository if someone remotely pushes to it. I think!!!)

Public repositories are bare repositories, they do not have working directory.

Create a bare repository with,

$ git init --bare <path>.git

Bare repositories only function as storage facilities.

A push to a origin/master may be aborted because your local branch is not in sync.
Synchronise with a central repository,

$ git fetch origin master
$ git rebase origin/master
$ git push origin master

GIT Notes: Branches

GIT Succinctly – free eBook from Synfusion

    Chapter 5 Branches

A new branch is a new development environment with an isolated working directory, staging and project history.
‘git branch’ is used for listing, creating, and deleting branches.
To view existing branches,

$ git branch

The output will indicate the currently checkedout branch with an asterisk.
The master branch is git’s default branch.
Create a new branch,

$ git branch <branch-name>

This does not switch you to the new branch, only creates a pointer to the current HEAD. (but I thought HEAD was the current commit!)
To switch branch,

$ git checkout <branch-name>

Initially both branches reference the same commit, but any new commits will be exclusive to the current branch and so each branch will have a HEAD of its own.
To delete a branch,

$ git branch -d <branch-name>

This will not delete branches with unmerged conflicts, to force the deletion,

$ git branch -D <branch-name>

After switching to a new branch, your working directory is updated to match the specified branche’s commit. (I think this just means, the latest commit or HEAD will be on this branch. Isn’t that obvious, since the HEAD is another name for the latest commit? Or maybe the HEAD is always the latest commit, but will take it from the checked out branch.)
Make sure your working directory is ‘clean’, meaning no uncommitted changes, before checking out another branch. Otherwise ‘git checkout’ could overwrite your modifications.
Using ‘git checkout’ with tags and commit IDs puts you in a detached HEAD state. his means you are not on a branch anymore, you are directly viewing a commit and will lose all work as soon as you switch to a real branch.
Creating a new branch in a detached HEAD state,

$ git checkout -b <new-branch-name>

This is a new branch reference to the formerly detached state.
In this case ‘-b’ is a shortcut for the two commands,

$ git branch <new-branch-name>
$ git checkout <new-branch-name>

(But how do you use ‘git checkout’ with tags and commit IDs to create a detached HEAD state.)
Merging is the process of pulling commits from one branch into another.
Merge methodologies: “fast-forward” merge, or a “3-way” merge.
The branch you want to merge into must be checked out and the target branch will remain unchanged.
To merge a branch called ‘sidebranch’ in master,

$ git checkout master
$ git merge sidebranch

This leaves sidebranch unchanged.
“fast-forward” merge: I create a new branch off master and add two commits to it, this type of merge syncs master with that latest branch commit. Master then contains all desired history and the branch can be deleted.
This was a simple situation because there were no extra commits on the master. If there are use a “3-way” merge.
“3-way” merge: I create a new branch off master and add two commits, during which time the master gets a new commit. To merge git generates a new merge commit, a combined snapshot of both branches. This commit has two parents commits and a history from both branches.
After using,

$ git checkout master

both types of merge use the same command,

$ git merge sidebranch

Two branches that make different changes to the same code portion is a merge conflict. This can not occur in a “fast-forward” merge.
When a merge conflict occurs use,

$ git status

If you get a merge conflict open the file and you’ll see something like,

<<<<<<< HEAD
This content is from the current branch.
This is a conflicting change from another branch.
>>>>>>> some-feature

Delete the content you don’t want including all of the <<<<<< , ======= , >>>>>>> lines also.
Then do,

$ git add <file>


$ git commit

Rebasing requires a branch to be checked out,

$ git checkout branch

Then to move the entire branch onto the tip of master,

$ git rebase master (but what happens to the branch then?)

This results in the same snapshot as if branch was merged with master.
“3-way” merge results in an extra merge commit. Rebasing has no extra commits and results in a cleaner linear history.
Change commits as you’re moving them to the new base, by specifying an interactive rebase,

$ git rebase -i master

This populates an editor with commits from the branch.
Specify an interactive rebase as follows,

pick 58dec2a First commit for new feature
squash 6ac8a9f Second commit for new feature

‘pick’ moves the first commit to the new base just as in ‘git rebase’. ‘squash’ combines the second commit with the previous one, so you end up with one commit containing all the changes.
Interactive rebasing lets you rewrite a branches history, you can add intermediate commits, then go back and fix them into more meaningful progression afterwards.
never rebase a branch that has been pushed to a public repository

GIT Notes: Undoing Changes

GIT Succinctly – free eBook from Synfusion

    Chapter 4 Undoing Changes

Undoing changes in git could mean,

  • Undo changes in working directory
  • Undo changes in staging area
  • Undo a entire commit

Changes can be made by deleting a commit or by using a new commit to undo changes introduced by the first commit.
The recent commit is the ‘HEAD’.
Make the working directory and the stage, match the files in the most recent commit. (This will actually change files in your working directory!!!)

$ git reset
$ git reset --hard HEAD (not sure about difference between these?)

To get rid of (meaning to delete) untracked files,

$ git clean

‘-f’ option forces deletion of these files,

$ git clean -f

(What is the difference between an ‘option’ e.g ‘-f’ and a ‘flag’ e.g. –hard? Or are these terms used interchangeable? Perhaps options are single character and reppended with a single hyphen and flag are mutiple charactered and preppended with double hyphens?)
A ‘reset –hard’ makes all files in the working directory and staging sync with the lastest commit.
Make a single file in the working directory match the version in the most recent commit, (bypasses staging)

$ git checkout HEAD

You can replace HEAD with a commit ID, branch or tag to make the file match the version in that commit. This command is like
NB Do Not Try this with ‘git reset’
To unstage a file,

$ git reset HEAD

This will not change the working directory.
To reset every file in the working directory and staging,

$ git reset --hard HEAD

This results in an unstaged modification in ‘git status’.
Undoing commits:
‘reset’ will remove it from project history
‘revert’ which generates a new commit that gets rid of changes introduced in the original.
To move the HEAD reference back one commit,

$ git reset HEAD ~1

This removes the most recent commit. Or you can go back two commits with ‘~2’, this also removes the two most recent commits. Not good to do this on public projects with other collaborators.
Reverting adds a new commit that undoes the problem commit

$ git revert

This takes the changes in the specified commit, figures out how to undo them, and creates a new commit with the resulting changeset. This t=is the way to undo a commit with a public repository.
Replace a previous commit instead of creating a new one,

$ git commit --amend

This rewrites history!

GIT Notes: Recording Changes

GIT Succinctly – free eBook from Synfusion

    Chapter 3 Recording Changes

A ‘snapshot’ is a complete record of state of files, not of differences between other states.
‘staging’ allows you choose what changes go into the commit.
To stage files,

$ git add (can multiple files be listed here?)

or to stage all,

$ git add .

To stop tracking a file, in other words to delete it from the project but not the working directory,

$ git rm --cached(can multiple files be listed here)

To view status of working directory and staging area,

$ git status

To output status of every unstaged change in your working directory,

$ git diff

To output difference of all staged changes

$ git diff --cached

To display committed snapshots,

$ git log
$ git status (what does this get?)

We start with ‘working directory’. This is ‘staged’ with ‘git add .’ and it is now a ‘staged snapshot’ which can then be ‘commited’ to ‘history’. And I suppose it is then ‘pushed’ to a remote repo.
A ‘commit’ is a saved version or ‘snapshot’ of the project, containing user info, date, commit message and SHA-1 checksum of entire contents.
A ‘commit’ is a step removed from working directory.
To commit staged snapshot to and add it to the history of the current branch,

$ git commit

You’ll be asked for a commit message,
Alternatively if the message is short you can use,
$ git commit -m “commit messsage goes here”
Display current branch’s commits,

$ git log (already mentioned above)

For working directory and stage we use: git add, git rm, and git status
For commit history: git commit, and git log
To display each commit on a single line,

$ git log -oneline (is the single hyphen correct)

To display history of an individual file,

$ git log --oneline (is the double hyphen correct?)

Filter commits, display commits contained in but not in . Both arguments can be commit ID, branch name or a tag,

$ git log .. (this is not clear)

To see what files were effected by a particular commit, display a diffstat of the changes in each commit,

$ git log -stat

Tags are simple pointers to commits. Create a new tag,

$ git tag -a v1.0 -m "Stable release"

-a creates an annotated tag and -m lets you record a message.
List your existing tags,

$ git tag

GIT Notes: Overview & Configuration

GIT Succinctly – free eBook from Synfusion

    Chapter 1 Overview
  • working directory
  • staging
  • commited history
  • development branch
    Chapter 2 Configuration

Configuration file in home directory,

$ cat ~/.gitconfig

To git init a directory,

$ git init <path-to-directory>

Omit path to git init current directory.

Includes a directory ‘.git’.
‘clone’ downloads a complete copy of repo. Clone can be used instead (or as well as) ‘git init’.

$ git clone ssh://@/path/to/repo.git (never used ssh here before)

Could also

$ git clone