How to sync Github to Gitlab

How to sync Github to Gitlab

I, like a lot of people who have used Git, started out using Github. But I became a bit frustrated by the lack of some features that Gitlab had, but Github didn’t (unlike many, the decision to switch to Gitlab wasn’t because of Microsoft’s takeover of Github).

How to sync Github to Gitlab

I, like a lot of people who have used Git, started out using Github. But I became a bit frustrated by the lack of some features that Gitlab had, but Github didn’t (unlike many, the decision to switch to Gitlab wasn’t because of Microsoft’s takeover of Github).

However, very few online code editors worked with Gitlab, while many would work with Github. While it isn’t a big hassle, time spent doing manual tasks (i.e. uploading and downloading files) adds up. Although Gitlab has a web IDE, I prefer using a dark mode and it doesn’t have the functionality that some other IDEs (Codeanywhere and Gitpod, for example) have.

To solve this, I decided to sync my Github repositories to Gitlab. If I make a change on Github, it will be reflected on the Gitlab project.

Photo by Pankaj Patel on Unsplash

What you’re going to want to do is to sign up for Github, if you haven’t already. Create a repository on Github, or choose the one that you want to sync to Gitlab.

If you haven’t signed up for Gitlab, sign up now, choosing the “sign up with Github option”. If you’ve already signed up for Gitlab, go to your settings and find the button that says “connect to github”.

All the services that can be connected to Gitlab

Once you’ve connected your github and gitlab accounts, click the little + button to the left of the search bar. Click “new project”.

The new project area

You are then going to want to click on the tab that says “CI/CD for external repo”. Click “Connect repositories from Github.” Select your project (it can be a personal repo or a corporation repo). It will take a few minutes to sync, and then you’re done!

Please note that while changes on the github repo will be reflected on gitlab, if you change something on gitlab, it won’t be reflected on Github.


— Limo

Learn how to CI/CD with GitHub Actions and Docker

Learn how to CI/CD with GitHub Actions and Docker

In this post, you'll learn how to CI and CD a Node.JS Application Using GitHub Actions

Originally published by Abhinav Dhasmana at

This article will cover the following:

  • Use Docker instead of bare metal deployment
  • Use GitHub actions for continuous integration of your app
  • Use GitHub actions for continuous deployment by pushing the Docker image to a Docker registry (Docker Hub)

Our workflow will look like this

A workflow of a Node.js app deployed using GitHub actions

The complete source code is available on GitHub

Use Docker instead of bare metal deployment

Dockerizing an existing app is easy. All we need is a Dockerfile and an optional .dockerignore file. Below is a Dockerfile for our app.

FROM node:10.16.0-alpine

WORKDIR /source/github-action-example-node

COPY package.json /source/github-action-example-node

RUN cd /source/github-action-example-node && npm i --only=production

COPY . .

CMD ["sh", "-c", "node server.js"]

It copies our package.json, runs npm install and starts the server. To make sure our file is correct, we can run docker build -t abhinavdhasmana/github-action-example-node . from the root folder. If we run docker images , we will see our latest image. We can also run our container with docker run -d -p 3000:3000 abhinavdhasmana/github-action-example-node. Point the browser to http://localhost:3000/ and text will appear.

What are GitHub Actions and how do they work

‘GitHub Actions’ is an API that can react to any event, GitHub’s or our own events. For example, for every push event on the repository, we want our test cases to run.

For GitHub Actions to work, we need to create a .github/workflows folder. We need to create our workflows inside this folder. Let’s create push.yml. Here is what we want from our workflow:

On every push, perform these actions in the given order

  1. git clone the repo
  2. run npm install
  3. run npm lint
  4. run npm test
  5. build the docker image
  6. login to docker hub
  7. Push the image to docker hub

Since we have to run each of these commands inside a docker we have to declare a Dockerfile for each of these actions and run the command in those containers. This is, of course, very tedious and error-prone. Remember, GitHub Actions are code, so we can just reuse, edit and fork them as we do with any other piece of code.

This is how our push.yml would look like

on: push
name: npm build, lint, test and publish
name: build and publish
runs-on: ubuntu-latest
- uses: actions/[email protected]
- name: npm install
uses: actions/[email protected]
args: install
- name: npm test
uses: actions/[email protected]
args: run test
- name: npm lint
uses: actions/[email protected]
args: run lint
- name: docker build
uses: actions/docker/[email protected]
args: build -t abhinavdhasmana/github-action-example-node .
- name: docker login
uses: actions/docker/[email protected]
- name: docker push
uses: actions/docker/[email protected]
args: push abhinavdhasmana/github-action-example-node

GitHub actions file for npm actions and push to docker hub

Let’s dissect this file

line 1: We want to trigger our workflow when someone pushes the code to our repo

line 3–6: We are defining a job build-and-publish which runs on ubuntu-latest. Each job runs in a fresh instance of a virtual environment. A job can contain one or more steps .

line 8: This is step 1 of our application. Here we want to get our source code. We can write our own code to pull our source code or reuse an open source. The repo link is

line 9-12: This is step 2 of our workflow where we run npm install on our codebase. Again, we use an open source action at and pass install as an argument.

line 13–20: These are same as the last step except the argument passed to npm command.

line 21–24: We build a docker image of our code with the help of docker action and tag the image as abhinavdhasmana/github-action-example-node

line 25-29: This one is a little different where we want to login into docker hub. Here we use secrets which are passed as an env variables to our build. We can set these env variables in many ways. To set this up via GitHub, go to Settings-> Secrets and create new secrets

Store secrets in GitHub

line 30-33: We push the image to the docker hub with the tag we created in line 24.

If we commit these changes, GitHub Actions will come into play and start running all the steps in our job. We should see something like this

GitHub Actions running our job

To validate if a new image has been pushed to DockerHub, we should see a new image being pushed in Docker Hub

Docker Hub image

Full source code is available on GitHub.

Thanks for reading

If you liked this post, share it with all of your programming buddies!

Follow me on Facebook | Twitter

Further reading

Docker and Kubernetes: The Complete Guide

Docker Mastery: The Complete Toolset From a Docker Captain

Docker for the Absolute Beginner - Hands On - DevOps

Docker for Absolute Beginners

How to debug Node.js in a Docker container?

Docker Containers for Beginners

Deploy Docker Containers With AWS CodePipeline

Build Docker Images and Host a Docker Image Repository with GitLab

How to create a full stack React/Express/MongoDB app using Docker

20+ Outstanding Vue.js Open Source Projects

20+ Outstanding Vue.js Open Source Projects

There are more than 20 Vue.js open-source projects in this article. The goal was to make this list as varied as possible.

There are more than 20 Vue.js open-source projects in this article. The goal was to make this list as varied as possible.

In this short intro, I won’t go back to the history of the Vue.js or some statistics on the use of this framework. Now it is a matter of fact that Vue is gaining popularity and projects listed below are the best evidence of its prevalence.

So here we go!


Opinionated code formatter



**GitHub **:

GitHub Stars: 32 343

Prettier reprints your code in a consistent style with several rules. Using a code formatter you don’t have to do it manually and argue about what is the right coding style anymore. This code formatter Integrates with most editors (Atom, Emacs, Visual Studio, Web Storm, etc. and works with all your favorite tools such as JavaScript, CSS, HTML, GraphQL, etc. And last year Prettier started to run in the browser and support .vue files.

Image source:

Image source:


Material Component Framework



GitHub Stars: 20 614

This framework allows you to customize visual components. It complies with Google Material Design guidelines. Vuetify combines all the advantages of Vue.js and Material. That is more Vuetify is constantly evolving because it has been improved by both communities on GitHub. This framework is compatible with RTL and Vue CLI-3. You can build an interactive and attractive frontend using Vuetify.

Image source:


A set of UI components



GitHub Stars: 21 643

Developers of all skill levels

can use iView but you have to be familiar with a Single File Components

( "") A friendly API and

constant fixes and upgrades make it easy to use. You can use separate

components (navigation, charts, etc.) or you can use a Starter Kit. Solid documentation of the iView is a big plus and of course, it is compatible with the latest Vue.js. Please note that it doesn’t support IE8.

Image source:

Image source:


A tab page


GitHub Stars: 124

A tab page gives easy access to RSS feeds, weather, downloads, etc. Epiboard focuses on customizability to provide a user with a personalized experience. You can synchronize your settings across your devices, change the feel and look and add your favorite bookmarks. This project follows the guidelines of the material design. The full list of the current cards you can find on the GitHub page.

Image source:

Light Blue Vue Admin

Vue JS Admin Dashboard Template




GitHub Stars: 28

Light Blue is built with latest Vue.js and Bootstrap has detailed documentation and transparent and modern design. This template is easy to navigate, has user-friendly functions and a variety of UI elements. All the components of this template fit together impeccably and provide great user experience. Easy customization is another big plus, cuts dramatically development time.

Image source:

Image source:


Account Security Scanner



GitHub Stars: 110

This security scanner was built with Vue.js and Ionic. It runs security checks and keeps passwords safe. So how this check is working? Beep simply compare your data with all the information in the leaked credentials databases. Your passwords are safe with Beep thanks to the use of the SHA-1 algorithm. Plus this app never stores your login and password as it is.

Image source:

Sing App Vue Dashboard

Vue.JS admin dashboard template




GitHub Stars: 176

What do you need from an admin template? You definitely need classic look, awesome typography and the usual set of components. Sing App fits all these criteria plus it has a very soft color scheme. A free version of this template has all the necessary features to start your project with minimal work. This is an elegantly designed dashboard can be useful more the most of web apps like CMS, CRM or simple website admin panel.

Image source:

Image source:

Vue Storefront

PWA for the eCommerce



GitHub Stars: 5 198

This PWA storefront can connect almost with any backend for the eCommerce because it uses headless architecture. This includes popular BigCommerce platform, Magento, Shopware, etc. Vue Storefront isn’t easy to learn at once because it is a complex solution. But it gives you lots of possibilities and it always improving thanks to growing community of professionals. Some of the advantages of Vue Storefront include mobile-first approach, Server-Side Rendering (good for SEO) and offline mode.

Image source:

Cross-platform GUI client for DynamoDb


GitHub Stars: 178

DynamoDB is a NoSQL database applicable in cases where you have to deal with large amounts of data or serverless apps with AWS Lambda. This GUI client gives remote access plus supports several databases at the same time.

Image source:


Interactive organization chart



GitHub Stars: 44

With this solution, no webserver, install or database needed. This simple chart can be edited in excel or webpage. You can easily search for a particular manager or department. Also, there are two options for usage. First as a static website. This option is suitable for you if you want to use vueOrgChart without modification. If you are planning to build your own chart on top of this project you will have to study the section “Build Setup”.

Image source:


Favicon generator




GitHub Stars: 63

This library helps you to create a simple icon. The first step is to pass in a configuration, and second, choose the format of your icon. You can choose JPG, PNG or SVG format. As you can see in the screenshot you can choose any font from the Google Fonts.

Image source:

Minimal Notes

Web app for PC or Tablet



GitHub Stars: 48

There is not much to say about this app. It is minimalistic, works on a browser locally, stored in localStorage and the file is only 4Kb. It is also available for Mac OS but the file form 4KB becomes 0.45 Bb. But it is still very lightweight.

Image source:


CMS built with Vue.js




GitHub Stars: 4 607

Directus is a very lightweight and simple CMS. It has been modularized to give the developers the opportunity to customize it in every aspect. The main peculiarity of this CMS is that it stores your data in SQL databases so it can stay synchronized with every change you made and be easily customized. It also supports multilingual content.

Image source:


Static Site Generator



GitHub Stars: 12 964

The creator of Vue.js, Evan You, created this simple site generator. Minimalistic and SEO friendly it has multi-language support and easy Google Analytics integration. A VuePress site is using VueRouter, Vue, and webpack. If you worked with the Nuxt or Gatsby you will notice some familiarities. The only difference is that Nuxt was created to develop applications and VuePress is for building static websites.

Image source:


Documentation site generator



GitHub Stars: 10 105

This project has an impressive showcase list. The main peculiarity of this generator lies in the way pages are generated. It simply grabs you Markdown file and displays it as a page of your site. Another big plus of this project is a full-text search and API plugins. It supports multiple themes and really lightweight.

Image source:


Standard Tooling for Vue.js Development



GitHub Stars: 21 263

This well-known tooling was released by the Vue team. Please note that before starting to use it you should install the latest version of Vue.js, Node.js, NPM, and a code editor. Vue CLI has a GUI tool and instant prototyping. Instant prototyping is a relatively new feature. It allows you to create a separate component. And this component will have all “vue powers” as full Vue.js project.

Image source:


Spreadsheet Parser and Writer




GitHub Stars: 16 264

SheetJS is a JS library that helps you to operate data stored in excel file. For example, you can export a workbook on browser-side or convert any HTML table. In other words, SheetJS doesn’t involve a server-side script, or for example AJAX. This the best solution for front-end operation of two-dimensional tables. It can export and parse data and run in node terminal or browser side.

Image source:


Browser devtools extension


GitHub Stars: 13 954

Almost any framework provides developers with a suitable devtool. This is literally an additional panel in the browser which very differs from the standard one. You don’t have to install it as a browser extension. There is an option to install it as a standalone application. You can activate it by right-click the element and choose “Inspect Vue component” and navigate the tree of components. The left menu of this tool will show you the data and the props of the component.

Image source:


Data Grid Component



GitHub Stars: 12 049

This component has a spreadsheet look, can be easily modified with a plugin and binds to almost any data source. It supports all the standard operations like read, delete, update and create. Plus you can sort and filter your records. What is more, you can include data summaries and assign a type to a cell. This project has exemplary documentation and was designed as customizable as it needs to be.

Image source:

Vue webpack boilerplate



GitHub Stars: 9 052

Vue.js provides great templates to help you start the development process with your favorite stack. This boilerplate is a solid foundation for your project. It includes the best project structure and configuration, optimal tools and best development practices. Make sure this template has more or less the same features that you need for your project. Otherwise, it is better to use Vue CLI due to its flexibility.

Image source:

Material design for Vue.js



GitHub Stars: 7 984

What is great about this Material Design Framework is truly thorough documentation. The framework is very lightweight with a full array of components and fully in line with the Google Material Design guidelines. This design fits every screen and supports every modern browser.

Image source:


Click-to-copy CSS effects



GitHub Stars: 4 569

This project is very simple and does exactly what is said in the description line. It’s a collection of CSS effects. You can see a preview of each effect and click on it. You will see a pop up with a code snippet that you can copy.

Image source:




GitHub Stars: 4 323

This is a collection of linear gradients which allows you to copy CSS codes. The collection is community contributed and has the opportunity to filter gradients based on preferred color.

Image source:




GitHub Stars: 5 568

Vuestic is a responsive admin template that already proving popular at the GitHub. Made with Bootstrap 4 this template doesn’t require jQuery. With 36 UI ready-to-use elements and 18 pages, Vuestic offers multiple options for customization. The code is constantly evolving not only due to the efforts of the author but also because of the support of the Vue community on GitHub.

Image source:

How to implement CI/CD into Spring-Boot-based Java Applications?

How to implement CI/CD into Spring-Boot-based Java Applications?

You'll learn how to implement CI/CD on a Spring Boot Java app using Maven, GitHub, Travis CI, Docker, Codecov, SonarCloud, and Heroku.

I am very excited to share my experiences building Continuous Integration/Continuous Delivery (CI/CD) into Spring-Boot-based Java applications. First, let's establish everything we will learn in this tutorial:

Step 1) Create a Spring Boot Java App using Spring Initializr

Step 2) Create a GitHub repository

Step 3) Use Travis CI and Docker to implement CI/CD

Step 4) Add Codecov to provide code coverage

Step 5) Use SonarCloud to write stellar code

Step 6) Build a project site using GitHub site-maven-plugin

Step 7) Deploy the app on Heroku using heroku-maven-plugin

Step 8) Manage topics

Gradually, we'll add badges to the file so that we can be notified in real-time on the state of Travis CI, Docker, Codecov, and SonarCloud. Also, we'll add the license badge.

Are you ready? If not take time to better understand or prepare yourself and continue to read this later. The code is available here. So just fork, it's all yours!

Step 1: Create a Spring Boot Java App Using Spring Initializr

In this project, I used Spring Tool Suite 4 (STS 4) IDE; you are free to use whatever tool you find suitable for this project. STS 4 has the Spring Initializr built-in, so that's why I chose it for this project.

This is what STS 4 dark theme looks like:

STS 4 - Home

Click on File -> New -> Spring Starter Project

You will get:

STS 4 - Form

Please fill out the form as follows:

Name: cicd-applied-to-spring-boot-java-app

Group: com.cicd

Artifact: cicd-applied-to-spring-boot-java-app

Description: Implementing CI/CD on Spring Boot Java App

Package: com.cicd.cicd-applied-to-spring-boot-java-app

By default:

Type: Maven

Packaging: jar

Java Version: 8

Language: Java

You will get:

![STS 4 - Form completed]( - Form completed")

Then, click Next.

Click on Spring Web:

![STS 4 - Spring Web]( - Spring Web")

Click on Finish. The new project will appear:

STS 4 - New project finally created

Next, please open the file.

We can then add a basic endpoint:

STS 4 - CicdAppliedToSpringBootJavaAppApplication edited

Right click -> Run As -> Maven build

STS 4 - Maven build

Then you will receive:

STS 4 - Edit configuration

To run the app, please add the following:

Goals -> spring-boot:run

STS 4 - Goals

Click Run:

STS 4 - Run

The final result can be found here: http://localhost:8080/

STS 4 - Final result

Now, on to the next step!

Step 2: Create a GitHub Repository

First, you need to sign in or sign up. I'm already a GitHub user so I just signed in. You will be directed to the homepage:

GitHub - Home

To create a new repository, click on green button "**New" **or click here. You will then be directed here:

GitHub - New repository

Please fill out the form as follows:

Repository name: cicd-applied-to-spring-boot-java-app (I chose to set the same name as the artifact field from step one)

Description: Implementing Continuous Integration/Continuous Delivery on Spring Boot Java App

Click on Public

Click on Initialize this repository with a README

Select the MIT license.

Why? It's very simple. The following links are helpful to better understand why you need an MIT license. Here's how to choose an open-source license and how open-source licenses work and how to add them to your projects.

Later, we'll add the .gitignore file.

Then, click on Create repository:

GitHub - Repository form completed

This is the new repository:

GitHub - New repository

I suggest you add a file named Why? While working on a project, you may face difficulties and need to ask for help. The goal is to save time when solving problems or fixing bugs.

To create it, please click on Create new file:

GitHub - Create new file

Then, fill the name field with and edit the file as follows. CI/CD is an example of research and the links represent results. "##" makes bold text.

GitHub -

Furthermore, click on the green button "**Commit new file" **at the bottom of the page:

GitHub - Commit new file

This is what we get:

GitHub - is created

Now, please install Git (Git installation can be found here) and GitHub Desktop (GitHub Desktop installation can be found here).

After installing these two tools, it's time to clone the project we started in step one.

Open GitHub Desktop and select the repository we created previously as follows:

Click on File -> Clone repository...:

GitHub - Desktop clone repository

You'll get this pop-up:

GitHub - Desktop pop-up

Just fill the search bar with "cicd;" you will find the repository: "cicd-applied-to-spring-boot-java-app" among the results:

GitHub - Desktop search bar

Select the repository and click on Clone:

GitHub - repository selected

GitHub Desktop is cloning the repository:

GitHub - Cloning repository

The repository is already cloned:

GitHub - Repository already cloned

At this stage, open the repository folder. This is my path:

My repository folder contains three files: LICENSE,, and shown below:

GitHub - Repository folder

It's time to open the folder where the code is saved:

GitHub - STS 4 project folder

Copy the content from the code folder and paste it into the repository folder. The repository folder looks as follows:

Github - Repository folder changed 1

It's important to ignore files and folders. We will not directly modify these files when working on a project. In order to do that, we'll make some changes to the .gitignore file from the repository folder. I used Sublime Text to edit that file.

Here's what it should look like before any changes:

GitHub - .gitignore before

Here's what it will look like after making changes.

First, add: .gitignore. It should look like:

GitHub - .gitignore after

Now, this is what folder repository looks on GitHub Desktop:

GitHub - 5 changed files

Fill the summary field with "First Upload" and click "Commit to master":

GitHub - First Upload

So what's next? Click on Push origin:

GitHub - Before push origin

GitHub - After Push origin

The repository is now up-to-date on GitHub:

GitHub - up-to-date

Step 3: Use Travis CI and Docker to Implement CI/CD

Note: If you're not familiar with either of these tools, check out this Travis CI Tutorial and Docker Getting Started tutorial to help you get started.

Sign up or sign in with GitHub and make sure Travis CI has access to your repository. Then, create a file named .travis.yml, which contains instructions that Travis CI will follow:

At first, this is what I get:

Travis - Create .travis.yml 1

Then, click on .travis.yml file:

Travis - Create .travis.yml 2

This is the repository on Travis CI:

Travis - First build passing

Now, we'll add a Travis CI badge so that we are notified about changes, etc.

To edit the file, please click on the pencil icon:

Travis - Click on pencil icon

We'll get this page:

Travis - Opening

Add this text but replace "FanJups" with your Travis CI username:

Travis - Adding Travis build status

Then, add a commit description "Adding Travis CI badge" and click on the Commit changes button:

Travis - Adding Badge Commit description

Then, we get:

Travis - Badge already added

It's important to know that, for every change you make, Travis CI will trigger a build and send an email. It's a continuous process:

Travis - Build related to adding badge

We successfully added Travis CI and its badge. Next, we'll focus on Docker.

First, sign in or sign up on Docker Hub:

Docker - Docker Hub Home Page

Click on the Create Repository button:

Docker - Create Repository Page

Fill out the form as follows:

Name: cicd-applied-to-spring-boot-java-app (GitHub repository name)

Description: Implementing Continuous Integration/Continuous Delivery on Spring Boot Java App (GitHub repository description)

Visibility: choose Public

Build Settings: select GitHub

After clicking on the Create button:

Docker - Repository already created

It's time to link our Docker repository to our GitHub repository. Click on Builds:

Docker - Builds

Then, click on Link to GitHub:

Docker - Link source providers

Select your GitHub repository:

Docker - Selecting GitHub Repository

Now that the GitHub repository is selected, we need to make some changes:

Autotest: select Internal and External Pull Requests

Repository links: select Enable for Base Image

Docker - Configuring builds 1

Docker - Configuring builds 2

Click on Save:

Docker - Github is now linked to Docker

We succeed to link our GitHub repository to the Docker repository. If you need help with Docker builds, this link is helpful.

What's next? First, we'll install Docker. Then we'll make some changes to the code and Travis CI.

To install Docker, go to Docker's Get Started page, select Docker for Developers and click on Download Desktop and Take a Tutorial:

Docker - Download Desktop

To make sure you've installed Docker and verify it's running properly, open your command line and write "docker." Then validate:

Docker - Command Line

Now, go back to your IDE or text editor; we'll make some changes to the code.

Create a file named "Dockerfile." To sum up what we've done so far, the Dockerile is useful when creating Docker images. To better understand the purpose of this file, this Dockerfile reference will help you.

To keep things simple, I use this Callicoder Dockerfile example and make little changes. This is what the Dockerfile looks like:

Here's the Dockerfile creating a process using STS 4:

Select the project, then click on New -> File

Fill the file name field with "Dockerfile" and click the Finish button:

Docker - Dockerfile 2

Copy and paste the content of Dockerfile presented previously:

Docker - Dockerfile is ready

Before making some changes to the pom.xml, let's look at the actual content:

We add Spotify's dockerfile-maven-plugin to push the project on Docker Hub:

"... to ensure the jar is unpacked before the Docker image is created, we add some configuration for the dependency plugin."

To continue, we will link Travis CI to Docker from our GitHub repository.

Do you remember your Docker username and password? Well, you will have to do so in order to proceed. We will create two environment variables in Travis CI.

To get there, just copy and paste this ( in your browser. But replace GITHUBUSERNAME with your correct username or click on your Travis CI badge present in

Travis CI-Docker - Travis CI Badge

Travis CI-Docker - Travis CI repository

Click on More options -> Settings :

Travis CI-Docker - Travis CI Settings

Travis CI-Docker - Travis CI Environment variables

Fill in the form as follows:


Value: yourdockerpassword

Click Add button


Value: yourdockerusername

Click Add button

Travis CI-Docker - Docker environment variables added

To deploy on Docker, we'll use "mvn deploy" as explained by Spotify. The Apache Maven Project explains the role of the Apache Maven Deploy Plugin as a plugin used to "add artifacts to a remote repository."

But we don't want to add artifacts to a remote repository, we just want to deploy it on Docker. So, when we call the deploy phase, we must include a valid section POM. However, that's not the purpose here. Thus, we'll add this property in pom.xml:


If we don't add this property, this error will occur:

"**[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project cicd-applied-to-spring-boot-java-app: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter -> [Help 1]**"

At this stage, it's time to use those two Docker environment variables. Just copy and paste this new .travis.yml and push it on GitHub:

Travis CI-Docker - Updating .travis.yml

Commit description: "Linking Travis CI to Docker"

We received a beautiful red cross and Travis CI badge, meaning a beautiful error! But ignore that for now, we'll correct it later!

Travis CI-Docker - red cross

Travis CI-Docker - Red Travis CI badge faiilure

Ladies and gentlemen, I'm happy to present to you: our beautiful error! Just go to the Travis CI repository and check out the beautiful build log:

The command "mvn deploy" exited with 1.

Travis CI-Docker - mvn deploy failed

We've already added the Travis CI badge. Now, it's time to do the same for Docker. Go to

On the search bar, write "docker." Then, we'll get the following results:

Travis CI-Docker - 1

Click on Docker Cloud Build Status:

Travis CI-Docker - 2

What if I told you we'll get an error here also?

Nevermind, just fill the following form:

Travis CI-Docker - Docker Build inaccessible

Click on the Copy Badge URL.

Now, go back to the GitHub repository and edit We'll add the following Docker badge:

Travis CI-Docker - Adding Docker badge

Commit description: "Adding Docker badge"

Travis CI-Docker - Adding Docker badge commit description

Ladies and gentlemen, we are all winners here. So let's get it right!

Previously, we made changes on the pom.xml and created a Dockerfile.

All of those errors occurred due to the fact that Maven didn't know how to handle the deployment on Docker and the Dockerfile was absent so it was impossible to push images.

The time has come to push those changes (Dockefile and pom.xml) on GitHub using GitHub Desktop:

Travis CI-Docker - Let's get it right

Ladies and gentlemen, who are we now? Winners!

Now, we have two ugly green badges meaning success! Just kidding! That's beautiful.

Travis CI - Docker - Success

To be sure, check your emails. You should have received two emails: one from Travis CI and the other from Docker.

Before moving on to step three, we'll run the app without using Docker only. Just remember to replace "fanjups" with your own Docker Hub username:

Travis CI - Docker - Running Docker Image

I got the following error: "Invalid or corrupt jarfile /app.jar." It's all about encoding, so I'll add those two properties to the pom.xml.

Now, it's time to commit on GitHub. If you're confused about writing useful commit messages,

Before running the app again, it's important to list all containers using docker ps.

Then check the "CONTAINER ID," stop (docker stop "CONTAINER ID"), and remove it (docker rm "CONTAINER ID") because it's persisted, as explained by this post on Spring Boot with Docker.

Then, we'll run again the app to ensure that everything works well:

Travis CI - Docker - Running Docker Image Successfully 1

Travis CI - Docker - Running Docker Image Successfully 2

I was so happy when I solved this problem!

The core steps are now over. We've successfully implemented the CI/CD. Now, let's add some useful tools!

Step 4: Add Codecov for Code Coverage

First, make sure you've updated the project on your computer:

Codecov - Pull Origin 2

Click on Pull Origin:

Codecov - Pull Origin 3

Copy the modified files which we'll use in IDE from our GitHub folder and then paste them into our workspace. In this case, we'll only copy and paste the pom.xml.

Don't forget to refresh the project on STS 4 and do whatever it takes to include changes.

To better use this tool, we make some changes by adding a unit test.

First, create a new package — com.cicd.cicdappliedtospringbootjavaapp.controller.

Secondly, create a new class and change as follows:

The folder looks like:

Codecov - folder

Before running the app on your computer, you can skip the entire dockerfile plugin because the deployment will take place on the GitHub repository managed by Travis CI.

To do this, just add this option (-Ddockerfile.skip), as explained by Spotify dockerfile-maven-plugin's usage, to your Maven command. Finally, we get mvn spring-boot:run -Ddockerfile.skip.

Now, log in or sign up to Codecov with GitHub.

Click on Account -> Repositories -> Add new repository

Just choose your GitHub repository or follow this link But remember to replace GITHUB_REPOSITORY with cicd-applied-to-spring-boot-java-app and the GITHUB_USERNAME with yours:

Codecov -  cicd-applied-to-spring-boot-java-app

Last time, we added two environment variables to Docker. Now, we added the Codecov environment variable: CODECOV_TOKEN, as well. Copy your token and add it to your Travis CI repository.

We made some changes to the pom.xml by adding the jacoco-maven-plugin.

Go back to GitHub repository and we'll edit .travis.yml.

What Time Is it? Codecov Badge Time!

Go to your Codecov repository and Click on **Settings -> Badge -> **Copy (from Markdown).

Then, go to your GitHub repository and paste it into

Finally, push your changes from your computer to GitHub.

Code Coverage: 60%

Codecov - Badge 60%

Perhaps, you want to deactivate the coverage and activate it later. If so, go ahead and create a file named codecov.yml. Now, it's useful to know coverage so I'll comment each line with "#."

If you wish to learn more, click here to read the docs.

Now, on to step 5!

Step 5: Use SonarCloud to Write Great Code

To start, log in or sign up with GitHub.

Click on + (Analyze new project or create new organization) -> **Analyze new project -> Import another organization -> Choose an organization on GitHub **

SonarCloud - Home

Next, make sure SonarCloud has access to your GitHub repository.

Now that we're back to SonarCloud, choose a Key. I suggest using "cicd-applied-to-spring-boot-java-app" as the Key.

Then, click on Continue -> Choose Free plan -> Create Organization -> Analyze new project -> Select your GitHub repository -> Set Up -> With Travis CI -> Provide and encrypt your token -> Copy

Go back to Travis CI and create a SonarCloud environment variable named SONAR_TOKEN. As a value, paste the token you've just copied.

Now, back to SonarCloud and click on Continue -> Edit your .travis.yml file -> Choose Maven as build technology -> Configure your platform -> Configure the scanner -> Copy.

I chose to write SonarCloud script under after_success instead of script because I focus on deployment here. You are free to place it where you want.

Also, create a file named and edit as follows: sonar.projectKey=GITHUBUSERNAME_cicd-applied-to-spring-boot-java-app

Go back to SonarCloud and click on Finish.

To end, we add a SonarCloud badge into

Here's the SonarCloud badge already added:

SonarCloud - Badge

Now, on to step 6!

Step 6: Build a Project Site Using the GitHub site-maven-plugin

To get started, open pom.xml on your computer. We add:

**1) OAuth token and GitHub servers ** as properties

2) org.apache.maven.plugins:maven-site-plugin

3) com.github.github:site-maven-plugin

4) org.apache.maven.plugins:maven-project-info-reports-plugin

5) developers section

6) organization section

7) issueManagement section

8) Software Configuration Management (SCM) section

"The important configuration is to allow the OAuth token to be read from an environment variable (excerpt from pom.xml)" as explained by Michael Lanyon's blog. _"To create the token, follow these instructions". _

Copy the token, then create a new environment variable named GITHUB_OAUTH_TOKEN.

Push pom.xml to GitHub and edit .travis.yml by adding "- mvn site" under after_success.

After pushing all changes, gh-pages branch and project site are created. Each time you push, the site will be updated if necessary.

GitHub Site - gh-pages branch

To see the site, click on environment -> View deployment (under Deployed to github-pages).

Here's a link to my GitHub repo.

GitHub Site - Home

Ok, great. Now, let's move on to step 7!

Step 7: Deploy the App on Heroku Using heroku-maven-plugin

Here we go! Log in or sign up for Heroku.

Heroku - Home

Click on New -> Create new app. To continue, enter an app name (cicd-spring-boot-java-app). cicd-applied-to-spring-boot-java-app is too long as an app name. Choose a region and click Create app.

Next, click Connect to GitHub.

Search the GitHub repository. Once you find it, click Connect.

Check** Wait for CI to pass before deploy.**

Click Enable Automatic Deploys.

Go to Account settings.

Heroku - Account settings

Copy your API KEY and create a new Travis CI environment variable named HEROKU_API_KEY. This the last environment variable linked to this project.


It's time to edit pom.xml and push to GitHub. We add:

1) full-artifact-name as a property

2) com.heroku.sdk:heroku-maven-plugin

Now, we focus on .travis.yml.

  1. To deploy on Docker Hub, we used mvn deploy.

  2. To deploy on Heroku, we'll use mvn heroku:deploy.

  3. In order to deploy on Docker and Heroku, we'll repeat the deploy phase twice, and risk exceeding timeout.

  4. To avoid that, we'll only use mvn heroku:deploy.

We succeeded in deploying on Heroku! Hooray! Now, go to

Heroku  - Succeesful Deployment

Now, it's time for the final step.

Step 8) Manage Topics

What does it mean to be in the last stage!? Topics are helpful when getting a quick overview of the project.

Go back to GitHub repository and click on Manage topics and add whatever you want.

By the way, we added a MIT license badge into the and license section of the pom.xml!

Final GitHub Repository 1

Final GitHub Repository 2


Congratulations! You're all done. To sum things up, you learned how to implement CI/CD on a Spring Boot Java app using Maven, GitHub, Travis CI, Docker, Codecov, SonarCloud, and Heroku. This is a template you are free to use.

If you're confused, please ask in the comments. I also suggest reading the docs available, as many times as necessary.

The code is available here. So just fork, it's all yours!

Git and Github: A Beginner’s Guide for Absolute Beginners

Git and Github: A Beginner’s Guide for Absolute Beginners

If you are a developer and you want to get started with Git and GitHub, then this article is made for you.

What is Git?

Git is a free, open-source version control software. It was created by Linus Torvalds in 2005. This tool is a version control system that was initially developed to work with several developers on the Linux kernel.

This basically means that Git is a content tracker. So Git can be used to store content — and it is mostly used to store code because of the other features it provides.

Real life projects generally have multiple developers working in parallel. So they need a version control system like Git to make sure that there are no code conflicts between them.

Also, the requirements in such projects change often. So a version control system allows developers to revert and go back to an older version of their code.

The branch system in Git allows developers to work individually on a task (For example: One branch -> One task OR One branch -> One developer). Basically think of Git as a small software application that controls your code base, if you’re a developer.

Git Repositories

If we want to start using Git, we need to know where to host our repositories.

A repository (or “Repo” for short) is a project that contains multiple files. In our case a repository will contain code-based files.

There are two ways you can host your repositories. One is online (on the cloud) and the second is offline (self-installed on your server).

There are three popular Git hosting services: GitHub (owned by Microsoft), GitLab (owned by GitLab) and BitBucket. We’ll use GitHub as our hosting service.

Before using Git we should know why we need it

Git makes it easy to contribute to open source projects

Nearly every open-source project uses GitHub to manage their projects. Using GitHub is free if your project is open source, and it includes a wiki and issue tracker that makes it easy to include more in-depth documentation and get feedback about your project.

If you want to contribute, you just fork (get a copy of) a project, make your changes, and then send the project a pull request using GitHub's web interface. This pull request is your way of telling the project you're ready for them to review your changes.


By using GitHub, you make it easier to get excellent documentation. Their help section and guides have articles for nearly any topic related to Git that you can think of.

Integration options

GitHub can integrate with common platforms such as Amazon and Google Cloud, with services such as Code Climate to track your feedback, and can highlight syntax in over 200 different programming languages.

Track changes in your code across versions

When multiple people collaborate on a project, it’s hard to keep track of revisions — who changed what, when, and where those files are stored.

GitHub takes care of this problem by keeping track of all the changes that have been pushed to the repository.

Much like using Microsoft Word or Google Drive, you can have a version history of your code so that previous versions are not lost with every iteration. It’s easy to come back to the previous version and contribute your work.

Showcase your work

Are you a developer who wishes to attract recruiters? GitHub is the best tool you can rely on for this.

Today, when searching for new recruits for their projects, most companies look at GitHub profiles. If your profile is available, you will have a higher chance of being recruited even if you are not from a great university or college.

Now we’ll learn how to use Git & GitHub

GitHub account creation

To create your account, you need to go to GitHub's website and fill out the registration form.

Git installation

Now we need to install Git's tools on our computer. We’ll use CLI to communicate with GitHub.

For Ubuntu:

  1. First, update your packages.
sudo apt update

2. Next, install Git and GitHub with apt-get

sudo apt-get install git

3. Finally, verify that Git is installed correctly

git --version

4. Run the following commands with your information to set a default username and email when you’re going to save your work.

git config --global "MV Thanoshan"
git config --global "[email protected]"
Working with GitHub projects

We’ll work with GitHub projects in two ways.

Type 1: Create the repository, clone it to your PC, and work on it.(Recommended)

Type 1 involves creating a totally fresh repository on GitHub, cloning it to our computer, working on our project, and pushing it back.

Create a new repository by clicking the “new repository” button on the GitHub web page.

Pick a name for your first repository, add a small description, check the ‘Initialize this repository with a README’ box, and click on the “Create repository” button.

Well done! Your first GitHub repository is created.

Your first mission is to get a copy of the repository on your computer. To do that, you need to “clone” the repository on your computer.

To clone a repository means that you're taking a repository that’s on the server and cloning it to your computer – just like downloading it. On the repository page, you need to get the “HTTPS” address.

Once you have the address of the repository, you need to use your terminal. Use the following command on your terminal. When you’re ready you can enter this:

git clone [HTTPS ADDRESS]

This command will make a local copy of the repository hosted at the given address.

Now, your repository is on your computer. You need to move in it with the following command.


As you can see in the above picture, my repository name is “My-GitHub-Project” and this command made me go to that specific directory.

**NOTE:**When you clone, Git will create a repository on your computer. If you want, you can access your project with the computer user interface instead using the above ‘cd’ command on the terminal.

Now, in that folder we can create files, work on them, and save them locally. To save them in a remote place — like GitHub – we have do a process called a “commit”. To do this, get back to your terminal. If you closed it, like I previously stated, use the ‘cd’ command.


Now, in the terminal, you’re in your repository directory. There are 4 steps in a commit: ‘status’ , ‘add’ , ‘commit’ and ‘push’. All the following steps must be performed within your project. Let's go through them one by one.

  1. “status”: The first thing you need to do is to check the files you have modified. To do this, you can type the following command to make a list of changes appear.
git status

2. “add”: With the help of the change list, you can add all files you want to upload with the following command,

git add [FILENAME] [FILENAME] [...]

In our case, we’ll add a simple HTML file.

git add sample.html

3. “commit”: Now that we have added the files of our choice, we need to write a message to explain what we have done. This message may be useful later if we want to check the change history. Here is an example of what we can put in our case.

git commit -m "Added sample HTML file that contain basic syntax"

4. “push”: Now we can put our work on GitHub. To do that we have to ‘push’ our files to Remote. Remote is a duplicate instance of our repository that lives somewhere else on a remote server. To do this, we must know the remote’s name (Mostly remote is named origin). To figure out that name, type the following command.

git remote

As you can see in the above image, it says that our remote’s name is origin. Now we can safely ‘push’ our work by the following command.

git push origin master

Now, if we go to our repository on the GitHub web page, we can see the sample.html file that we’ve pushed to remote — GitHub!

NOTE: Sometimes when you’re using Git commands in the terminal, it can lead you to the VIM text editor (a CLI based text-editor). So to get rid of it, you have to type


and ENTER.

Pulling is the act of receiving from GitHub.

Pushing is the act of sending to GitHub.

Type 2: Work on your project locally then create the repository on GitHub and push it to remote.

Type 2 lets you make a fresh repository from an existing folder on our computer and send that to GitHub. In a lot of cases you might have actually already made something on your computer that you want to suddenly turn into a repository on GitHub.

I will explain this to you with a Survey form web project that I made earlier that wasn’t added to GitHub.

As I already mentioned, when executing any Git commands, we have to make sure that we are in the correct directory in the terminal.

By default, any directory on our computer is not a Git repository – but we can turn it into a Git repository by executing the following command in the terminal.

git init

After converting our directory to a Git repository, the first thing we need to do is to check the files we have by using the following command.

git status

So there are two files in that directory that we need to “add” to our Repo.

git add [FILENAME] [FILENAME] [...]

NOTE: To “add” all of the files in our Repository we can use the following command:

git add .

After the staging area (the add process) is complete, we can check whether the files are successfully added or not by executing the git status

If those particular files are in green like the below picture, you’ve done your work!

Then we have to “commit” with a description in it.

git commit -m "Adding web Survey form"

If my repository started on GitHub and I brought it down to my computer, a remote is already going to be attached to it (Type 1). But if I’m starting my repository on my computer, it doesn’t have a remote associated with it, so I need to add that remote (Type 2).

So to add that remote, we have to go to GitHub first. Create a new repository and name it whatever you want to store it in GitHub. Then click the “Create repository” button.

NOTE: In Type 2, Please don’t initialize the repository with a README file when creating a new repository on the GitHub web page.

After clicking the “Create repository” button you’ll find the below image as a web page.

Copy the HTTPS address. Now we’ll create the remote for our repository.

git remote add origin [HTTPS ADDRESS]

After executing this command, we can check whether we have successfully added the remote or not by the following command

git remote

And if it outputs “origin” you’ve added the remote to your project.

NOTE: Just remember we can state any name for the remote by changing the name “origin”. For example:

git remote add [REMOTE NAME] [HTTPS ADDRESS]

Now, we can push our project to GitHub without any problems!

git push origin master

After completing these steps one by one, if you go to GitHub you can find your repository with the files!


Thank you everyone for reading. I just explained the basics of Git and GitHub. I strongly encourage you all to read more related articles on Git and GitHub. I hope this article helped you.

Happy Coding!

Top 40 Git Interview Questions and Answers

Top 40 Git  Interview Questions and Answers

Git plays a vital role in many organizations to achieve DevOps and is a must know technology. This reason drives me to prepare you for the most frequently asked Git interview questions. In this post, we have covered around top 40 Git interview questions and answers

1. What is your favorite Git command?

I am a sucker for git add -p. This adds changes in "patch mode" which is a built-in command line program. It iterates over each of my changes and asks me if I want to stage them?
This command forces me to slow down and review my changes. Too often as developers we rush this part thinking the work is done. I can't tell you how many times I've run git add . in a hurry to later realize I committed "scratch" files or debug statements.

2. Why do you prefer using Git from the command line?

As developers, we're already using the command line for so many other things. Why not for Git as well?
In addition, Git has a very small command set. One that is pretty easy to learn as a developer and will improve your development workflow by using it directly.

3. How can we use stage command?

stage is a built-in alias for add.

4. How can I save the changes in a branch and checkout to other branch?

So you may use git stash to temporarily store your changes or make a WIP commit. The goal is to have a clean working index.
Personally, I prefer working with WIP commits rather than stash. I find them easier to reference and potentially share.

5. When should I use git stash?

I like to use stash for quickly getting the "working index" clean.

6. How do I see how to use a Git command?

Use the --help option for any command. Example, git stash --help.

7. What is "git flow"?

git flow is a branching strategy using multiple "long-lived" branches which mirror the software development lifecycle. Changes are merged between these branches as work is needed.

8. What is "GitHub Flow"?

Basically GitHub Flow is a branded name for a master/feature branch workflow. GitHub has formalized this into a process using their toolset shown in this visual tutorial.

9. Which branching strategy do you prefer?

I've worked on hundreds of Git projects and I will say most reach for "git flow". Only a a handful of these projects ever needed that strategy. Often because it was versioned software.
The master/feature branching strategy is much easier to manage, especially when you're just starting out. And it's very easy to switch to "git flow" if needed.

10. What was the git open command you used?

It's a separate command and available as an npm package.

11. How can you reset a branch when there are files that were added in other branch but still appear as untracked or modified in your working branch?

This is often the result of switch branches when the "working index" is unclean.

There's no built in way to correct this with Git. I normally avoid this by ensuring my prompt has a "status" indicator and running commands like git status anytime I change a branch.

These habits give me an opportunity to catch this early so I can either stash or commit those changes working on a new branch.

12. How can I rename a branch ?

git branch -m current-branch-name new-branch-name

13. How I can use cherry-pick?

git cherry-pick [reference]. Remember this is a reapplying command, so it will change the commit SHA.

14. If I make a revert from a branch and (for example HEAD~3), is it possible to go back to HEAD again (like a recovery of your last updates?

In this scenario, I would immediately undo the revert commit (which is the HEAD commit) by running git reset --hard HEAD~1.

15. When use git pull and git fetch?

git pull will download the commits to your current branch. Remember, git pull is really the combination of the fetch and merge commands.
git fetch will retrieve the latest references from a remote.

A good analogy is with a podcast player or email client. You might retrieve the latest podcasts or emails (fetch), but you haven't actually downloaded the podcast or email attachments locally yet (pull).

16. Why sometimes we need use --force to push the changes of a rebase?

rebase is a command which may reapply commits which changes their SHA1 hash. If so, the local commit history will no longer align with its remote branch.

When this happens you will get a rejected push. Only when rejected should you consider using git push --force.

Doing so will overwrite the remote commit history with your local commit history. So always slow down and think about why you need to use --force.

17. Can you use a branch to merge multiple branches and then send this branch to master?

Absolutely. It's common under most of the Git workflows for branches to accumulate changes from multiple other branches. Ultimately these branches are "promoted" into the main branch.

18. Should I do a rebase from a very old branch?

Only if you have to.

Depending on your workflow, it may be possible to merge a stale branch into your main branch.

If you need to bring a branch up-to-date, I prefer rebase. It provides a cleaner history of only your changes instead of commits from other branches or merges.

However, while always possible, using rebase may be a painful process since each of your commits are reapplied. This may lead to multiple conflicts. If so, I normally --abort the rebase and use merge instead to resolve all the conflicts once.

19. When using rebase -i, what's the difference between squash and fixup?

Both squash and fixup combine two commits. squash pauses the rebase process and allows you to adjust their commit message. fixup automatically uses the message from the first commit.

20. Often when I rebase my feature branch with master, for each commit I need resolve conflicts?

Yes. Since the changes from each commit is reapplied during rebase, you have to resolve any conflicts as they happen.

This means a commit conflicts early in the process, or if you resolve it incorrectly, it's likely many of the following commits will conflict as well.

To limit this, I often use rebase -i to first condense my commit history so it is easier to work with.

If there are still conflicts across many commits, I may use merge instead.

21. Is necessary update my branch with master before merge it with master?

Depending on your workflow, it may be possible to merge a stale branch into your main branch.

If your workflow uses "fast-forward" only merges, then it will be necessary to update your branch before merging.

22. Do you recommend use GitKraken?

I am an advocate for using Git from the command line. I find this keeps me in full control of managing changes, as using commands to improve my development process.

Of course, certain visual actions like managing branches and viewing file differences will always be better in a GUI. Personally, I find viewing such things in the browser during the merge process to be enough.

23. Could you do an --amend of a commit when it already was pushed?

Yes. However, you would not want to amend a commit after it is merged into another branch since --amend changes the commit.

24. When I know I will work on something for a while, should I open a pull request for each change or a complete pull request for all the work?

You normally want to open a pull request for all the work.

However, if you are working on something for a long time. It might be beneficial to merge smaller changes along the way. Doing so will prevent dependencies on your branch or staleness.

This will depend on the type of changes you are making.

25. Is it good practice make a release branch before merge a branch to master?

This depends heavily on your deployment process. Creating a release branch can be beneficial to group together work from multiple branches and test them as a whole before merging them into your main branch.

Since the source branches remain separate and unmerged, you will have more flexibility in the final merge.

26. How to take just some commits from master? Let's say I don't want to take the last commit but do a rebase.

Assuming master is your main branch, you don't want to selectively pull commits from its history. This will cause conflicts later.

You will want to merge or rebase your branch will all the changes from master.

For pulling select commits from a branch other than your main branch, you can use git cherry-pick.

27. Are there some special themes that I can set up on my terminal?

I cover configuring and customizing your terminal in Getting Git.

28. Which option is best instead of use the command git push --force?

There really isn't an alternative to git push --force.

With that said, if you properly update your branch with merge or rebase you should not need to use git push --force.

Only when you have run commands which change your local commit history from the history you previously shared should git push --force be required.

29. When I select drop during git rebase -, is the code related to that commit deleted?


To revive this code, you will need to find a state prior to the rebase from the reflog.

30. How can we track automatically a remote branch?

Normally branch tracking is set up automatically by Git when you checkout or create a branch.

If not, you can update this the next time you push with: git push -u remote-name branch-name.

Or you can set it explicitly with:git branch --set-upstream-to=remote-name/branch-name

31. Is a best practice rebase a branch before updating it?

I believe so, simply for the reason organizing or collapsing your commits with git rebase -i first gives you more context during the update process.

32. Is there a way to split a commit into more commits (something inverse to fixup/squash)?

You could use the exec command during the rebase -i process to attempt to modify the working index and split up changes.

You can also use git reset to undo recent commits and place their changes in the working index to then separate their changes into new commits.

33. Is there a way to go or see a commit that was fixed up?

Not the previous commits. You can using git show to see the changes within the new commit?

34. What does rebase --skip?

This tells rebase to not apply the current changes during the rebase process.

35. How can I remove remote branches?

You can remove a remote branch by pushing "nothing" with:
git push origin :branch-name-to-remove or using the -d option with: git push -d origin some-other-branch-2.

To remove local reference to remote branches, you can run: git remote prune origin.

36. What's the difference between checkout and reset?

Both of these commands can be used to undo changes. checkout is arguably more robust as it allows you to not only undo current changes, but also undo a set of changes by retrieving an older version of a file.

reset, by default, works more with changing the state of changes within the working index. As such, it really only deals with the current changes.

I prefer reset. The wording makes more sense for the action, which is often to change the state or discard current changes. I tend to reserve checkout for switching branches and the rare occasion of restoring an old version of a file.

37. What commands should I avoid using in normal workflow?

Anything that could be destructive to your history, for example:

  • git push origin master -f (NEVER)
  • git revert (on a feature branch)
  • git cherry-pick (changes from master)
    Under a normal workflow, I try to avoid using git merge directly as this is often built into the process through pull requests.
38. If I have a branch (B) that points to other branch (A) and I have another branch (C) which needs code from (A) and (B) and master which process must follow to have (C) updated?

Interesting. This depends on a few things…

Are A and B something that can be merged into master? If so, you could merge A and B into master, and then update C with the latest changes from master.

If not, you may be able to simply merge B into C since it contains the changes from A already.

In the extreme case, you could merge A, B, and master into C. However, it's likely the order of merging would matter to avoid conflicts.

39. What are some of the aliases you use?

I don't alias Git commands often. Especially not core commands. I find doing so creates confusion, especially as a trainer.

With that said, I do have a few aliases for common commands or commands I use with a lot of options:

alias.unstage reset HEAD --
alias.append commit --amend --no-edit
alias.wip commit -m "WIP"
alias.logo log --oneline
alias.lola log --graph --oneline --decorate --all

40. What are some lesser known Git commands?

git bisect is a life-saver for finding an existing bug in the code. While I've only used it a few times, it has been impressively precise and saved hours of looking for a needle in a haystack.

git archive is another nice one for packaging up a set of changes. This can be helpful for sharing work with a third-party or mico-deployments.

git reflog is probably known, but worth mentioning as it provides a nice way to "undo" commands when things go wrong.