PWSLab Git Workshop - Useful commands and concepts

PWSLab Git Workshop - Useful commands and concepts


  1. A brief history of Git.
  2. PWSLab walkthrough.
  3. Configure your environment.
  4. Workshop.

Git Introduction

  1. Distributed version control.
  2. It does not rely on a connection to a central server.
  3. Many copies of the complete history.
  4. Powerful branching and merging.
  5. Adapts to nearly any workflow.
  6. Fast, reliable and stable file format.


Use the tools at your disposal when you get stuck.
  1. Use ‘git help <command>’ command.
  2. Use Google.
  3. Read the documentation at

Configure your Environment

  1. Windows: Install ‘Git for Windows’ -
  2. Mac: Type ‘git’ in the Terminal application. If it’s not installed, it will prompt you to install it.
  3. Debian (Ubuntu):sudo apt-get install git-all’ or Red Hatsudo yum install git-all

Git Workshop

  1. Configure Git.
  2. Configure SSH Key.
  3. Create a project.
  4. Committing.
  5. Feature branching.
  6. Merge requests.
  7. Feedback and Collaboration.
Configure Git

One-time configuration of the Git client:
git config --global "Your Name"
git config --global
Configure SSH Key
ssh-keygen -t rsa -b 4096 -C "you@computer-name"
# You will be prompted for the following information. Press enter to accept the defaults. Defaults appear in parentheses.
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/you/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/you/.ssh/id_rsa.
Your public key has been saved in /Users/you/.ssh/
The key fingerprint is:
39:fc:ce:94:f4:09:13:95:64:9a:65:c1:de:05:4d:01 you@computer-name
Copy your public key and add it to your PWSLab profile:
cat ~/.ssh/
ssh-rsa AAAAB3NzaC1yc2EAAAADAQEL17Ufacg8cDhlQMS5NhV8z3GHZdhCrZbl4gz

Create a Project

  1. Create a project in your user namespace.
    1. Choose to import from ‘Any Repo by URL’ and use
  2. Create a ‘development’ or ‘workspace’ directory in your home directory.
  3. Clone the ‘training-examples’ project.
Visit to learn more about how to create a new project. 

Commands (project)

mkdir ~/development
cd ~/development
mkdir ~/workspace
cd ~/workspace
git clone
cd training-examples

Git concepts

Untracked files
New files that Git has not been told to track previously.

Working area
Files that have been modified but are not committed.

Staging area
Modified files that have been marked to go in the next commit.


  1. Edit ‘edit_this_file.rb’ in ‘training-examples’.
  2. See it listed as a changed file (working area).
  3. View the differences.
  4. Stage the file.
  5. Commit.
  6. Push the commit to the remote.
  7. View the git log.

Commands (committing)

# Edit `edit_this_file.rb`
git status
git diff
git add 
git commit -m 'My change'
git push origin master
git log

Feature branching

  1. Efficient parallel workflow for teams.
  2. Develop each feature in a branch.
  3. Keeps changes isolated.
  4. Consider a 1-to-1 link to issues.
  5. Push branches to the server frequently.
    1. Hint: This is a cheap backup for your work-in-progress code.

Feature branching steps

  1. Create a new feature branch called ‘squash_some_bugs’.
  2. Edit ‘bugs.rb’ and remove all the bugs.
  3. Commit.
  4. Push.

Commands (feature branching)

git checkout -b squash_some_bugs
# Edit `bugs.rb`
git status
git add bugs.rb
git commit -m 'Fix some buggy code'
git push origin squash_some_bugs

Merge requests

  1. When you want feedback to create a merge request.
  2. Target is the ‘default’ branch (usually master).
  3. Assign or mention the person you would like to review.
  4. Add ‘WIP’ to the title if it’s a work in progress.
  5. When accepting, always delete the branch.
  6. Anyone can comment, not just the assignee.
  7. Push corrections to the same branch.

Merge requests steps

Create your first merge request:
  1. Use the blue button in the activity feed.
  2. View the diff (changes) and leave a comment.
  3. Push a new commit to the same branch.
  4. Review the changes again and notice the update.

Feedback and Collaboration

  1. Merge requests are a time for feedback and collaboration.
  2. Giving feedback is hard.
  3. Be as kind as possible.
  4. Receiving feedback is hard.
  5. Be as receptive as possible.
  6. Feedback is about the best code, not the person. You are not your code.

Feedback and Collaboration resources

Review the Thoughtbot code-review guide for suggestions to follow when reviewing merge requests:


  1. Useful for marking deployments and releases.
  2. Annotated tags are an unchangeable part of Git history.
  3. Soft/lightweight tags can be set and removed at will.
  4. Many projects combine an annotated release tag with a stable branch.
  5. Consider setting deployment/release tags automatically.

Tags steps

  1. Create a lightweight tag.
  2. Create an annotated tag.
  3. Push the tags to the remote repository.

Commands (tags)

git checkout master

# Lightweight tag
git tag my_lightweight_tag

# Annotated tag
git tag -a v1.0 -m ‘Version 1.0’
git tag

git push origin --tags

Merge conflicts

  1. Happen often.
  2. Learning to fix conflicts is hard.
  3. Practice makes perfect.
  4. Force push after fixing conflicts. Be careful!

Merge conflicts steps

  1. Checkout a new branch and edit conflicts.rb. Add ‘Line4’ and ‘Line5’.
  2. Commit and push.
  3. Checkout master and edit conflicts.rb. Add ‘Line6’ and ‘Line7’ below ‘Line3’.
  4. Commit and push to master.
  5. Create a merge request.

Merge conflicts commands

After creating a merge request you should notice that conflicts exist. Resolve the conflicts locally by rebasing.
git rebase master

# Fix conflicts by editing the files.

git add conflicts.rb
git commit -m 'Fix conflicts'
git rebase --continue
git push origin  -f

Rebase with squash

You may end up with a commit log that looks like this:
Fix issue #13
Fix again
Test again
Does this work?

Squash these into meaningful commits using an interactive rebase.

Rebase with squash commands

Squash the commits on the same branch we used for the merge conflicts step.
git rebase -i master
In the editor, leave the first commit as ‘pick’ and set others to ‘fixup’.

Have more questions? Please email us at
Also, let us know if the article is helpful!

    • Related Articles

    • List of PWSLab CI/CD Environment Variables

      Introduction This document enlists a set of pre-defined environment variables accepted by PWSLab CI/CD for the local environment of the Runner. These can be referenced directly in the .pwslab.yml file or via the Project's Settings > CI/CD > ...
    • How To Change Git Remote URL?

      Introduction Git remote is a pointer that refers to another copy of the repository that is usually hosted on a remote server. In some situations, like when the remote repository is migrated to another host, you need to change the remote’s URL. This ...
    • How to duplicate a Git repository? Repository mirroring simplified.

      To duplicate a repository without forking it, you can run a special clone command, then mirror-push to the new repository. Before you can duplicate a repository and push to your new copy, or mirror, of the repository, you must create the new ...
    • Simple steps to synchronise a Remote Fork in a Git repository

      Introduction When you collaborate in any upstream project (like an open-source project) it is likely to be asked to make a fork of the main repository. A fork is a copy of the project in your Git account. This duplicate allows you to freely ...
    • How to apply Git Patches?

      Patch is a text file, whose contents are similar to Git diff, but along with code, it also has metadata about commits; e.g., commit ID, date, commit message, etc. We can create a patch from commits and other people can apply them to their repository. ...