DEV Community: Maroun Maroun

A Short Journey to Git Internals

Maroun Maroun — Mon, 28 Sep 2020 14:24:23 +0000

In this article, we’ll dive into Git internals by going through a real example. If you don’t have your terminal open already, do so, fasten your seatbelts, and let’s go! 💨

Initializing a Git repository

You have probably already initialized an empty Git project using git init, but did you ever wondered what does this command do?

Let’s create an empty folder, and initialize an empty Git project. From the official Git documentation, git init:

This command creates an empty Git repository — basically a .git directory with subdirectories for objects, refs/heads, refs/tags, and template files. An initial HEAD file that references the HEAD of the master branch is also created.

If we inspect the folder’s content, we’ll see the following structure:

$ tree -L 1 .git/
.git/
├── HEAD
├── config
├── description
├── hooks
├── info
├── objects
└── refs

Git is a key-value datastore

At its core, Git is a content-addressable filesystem. Huh? 🤔 Ok, Git is simply a key-value database. You insert any kind of content into a Git repository, for which Git will give you back a unique identifier (a key) that you can use to retrieve that content back.

Git uses the hash-object command to store values into the database:

Computes the object ID value for an object with specified type with the contents of the named file (which can be outside of the work tree), and optionally writes the resulting object into the object database. Reports its object ID to its standard output. When is not specified, it defaults to “blob”.

“blob” is nothing but a sequence of bytes. A Git blob contains the exact data as a file, but it’s stored in the Git key-value data store, while the “actual” file is stored on the file system.

Let’s create a blob:

$ echo hello | git hash-object --stdin -w
ce013625030ba8dba906f756967f9e9ca394464a

We used the -w flag to actually write the object into the object database, and not only display it (achieved by the --stdin flag).

The value “hello” is the “value” in the Git data store, and the hash returned from the hash-object function is in this case our key. We can now do the opposite operation to read the value by its key, using the git-cat-file command:

$ git cat-file -p ce013625030ba8dba906f756967f9e9ca394464a
hello

We can check its type using the -t flag:

$ git cat-file -t ce013625030ba8dba906f756967f9e9ca394464a
blob

git hash-object stores the data in the .git/objects/ folder (AKA the object database). Let’s verify:

$ tree .git/objects/
.git/objects/
├── ce
│   └── 013625030ba8dba906f756967f9e9ca394464a
├── info
└── pack

The hash suffix (under the “ce” directory) is the same as the one we got back from the hash-object function, but it has a different prefix. Why? That’s because the parent folder name contains the first two characters of our key. Why? Because some file systems have limitations on numbers of sub-directories. So introducing this layer mitigates that problem.

Let’s save another object:

$ echo world | git hash-object --stdin -w
cc628ccd10742baea8241c5924df992b5c019f71

As expected, we’ll now have two directories under .git/objects/:

$ tree .git/objects/
.git/objects/
├── cc
│   └── 628ccd10742baea8241c5924df992b5c019f71
├── ce
│   └── 013625030ba8dba906f756967f9e9ca394464a
├── info
└── pack

and again, the cc folder, which has the key’s prefix, has the rest of the key in the contained file’s name.

Tree Objects 🌲

The next Git object we’ll investigate is the tree. This type solves the problem of storing the filename and allows storing a group of files together.
A tree object contains entries. Each entry is the SHA-1 of the blob, or subtree with its associated mode, type, and filename. Let’s check the git-mktree documentation:

Reads standard input in non-recursive ls-tree output format, and creates a tree object. The order of the tree entries is normalized by mktree so pre-sorting the input is not required. The object name of the tree object built is written to the standard output.

If you’re wondering about ls-tree output format, it looks like:

<mode> SP <type> SP <object> TAB <file>

Let’s now associate the two blobs above:

$ printf '%s %s %s\t%s\n' \
    100644 blob ce013625030ba8dba906f756967f9e9ca394464a hello.txt \
    100644 blob cc628ccd10742baea8241c5924df992b5c019f71 world.txt |
  git mktree
88e38705fdbd3608cddbe904b67c731f3234c45b

mktree returns a key for the newly created tree object.

At this point, we can visualize our tree as follows:

             88e38705fdbd3608cddbe904b67c731f3234c45b  
                                |                   
                  +-------------|------------+             
                  |                          |        
                  |                          |        
                  |                          |          
                  |                          |       
                  |                          |
                hello                       world        
            ce013625030b                 cc628ccd1074

Let’s view the tree’s content:

$ git cat-file -p 88e38705fdbd3608cddbe904b67c731f3234c45b
100644 blob ce013625030ba8dba906f756967f9e9ca394464a hello.txt
100644 blob cc628ccd10742baea8241c5924df992b5c019f71 world.txt

and of course, the .git/objects was updated accordingly:

$ tree .git/objects/
.git/objects/
├── 88
│   └── e38705fdbd3608cddbe904b67c731f3234c45b
├── cc
│   └── 628ccd10742baea8241c5924df992b5c019f71
├── ce
│   └── 013625030ba8dba906f756967f9e9ca394464a
├── info
└── pack

So far we have not updated our index. To do so, we use the git-read-tree command:

Reads the tree information given by into the index, but does not actually update any of the files it “caches”. (see: git-checkout-index[1])

$ git read-tree 88e38705fdbd3608cddbe904b67c731f3234c45b
$ git ls-files -s
100644 ce013625030ba8dba906f756967f9e9ca394464a 0 hello.txt
100644 cc628ccd10742baea8241c5924df992b5c019f71 0 world.txt

Note however, that we still don’t have the files on our file system, since we’re writing values directly to the Git datastore. In order to “checkout” the files, we’ll use the git-checkout-index command, which copies files from the index to the working tree:

git checkout-index 0 -a

The -a stands for “all”. Now we should be able to see our files:

$ ls
hello.txt world.txt
$ cat hello.txt
hello
$ cat world.txt
world

Summary 📝

In this article, we stored two files directly to the Git datastore. The files weren’t yet visible to our local filesystem. We’ve created a tree and associated the two “blobs” to it, and then we brought the files to our working directory using the git-checkout-index command.

Auto Link to Reference External Resources Based on the Reference ID in the Commit Message

Maroun Maroun — Wed, 01 Jul 2020 13:43:46 +0000

Configuring auto links to reference external resources is one of the most helpful features of GitHub.

Configuring it will make the commit message clickable, and it'll reference the external resource (i.e. Jira).

I thought it'd be very useful if you could do the same but from the CLI. So I wrote a simple script that does that.

You should have two variables set:

REFERENCE_PATTERN - Pattern used in commit message
TARGET_URL - Link to the external system you want to link to

For example, to link Jira issues having pattern like "PS-1425", you should set REFERENCE_PATTERN to PS-\d\d\d\d, and the TARGET_URL should be set to https://proteantecs.atlassian.net/browse.

Once set, you simply run:

gitlink <SHA>

If only one issue is referenced in the commit message, it'll be opened in the browser. Otherwise, you'll get a list of links for the issue.

For example, having the following log:

Author: MarounMaroun <****  .com>
Date:   Tue Jun 30 23:16:30 2020 +0300

    BD-5562: handle missing user in the user service

When you run:

gitlink 7d21af686732bd1812f79c4c51ac98a903de5c3d

A new tab with the relevant issue will be opened:

Project in GitHub: https://github.com/MarounMaroun/gitlink

GitHub Bash API

Maroun Maroun — Wed, 10 Jun 2020 19:32:47 +0000

I'm writing Bash scripts for the GitHub API in Bash.

This repo aims to expose basic functions for using the GitHub API in Bash, without any dependency on GitHub CLI tools.

You can copy any of the functions and use it wherever you want. For example, in your own GitHub action script.

Usage

Each file aggregates functions that are relevant for the specific API.

For example, the pull_request.sh script have functions that expose the Pull Requests API.

You can test each function by simply calling it inside the file. For example, to get the PRs count in some repository, you can call the prs_count function in the pull_requests.sh file, and then execute:

./pull_request.sh <token> <owner> <repo>

Which yields the number of PRs for the given repository.

I hope you find it useful! Your input is highly welcomed and appreciated.

Link to the repository: https://github.com/MarounMaroun/github-bash-api

My First GitHub Action!

Maroun Maroun — Fri, 29 May 2020 18:33:52 +0000

I wrote a GitHub action for running ShellCheck on shell files in your PR.

Usage

Create a file checker.yml inside .github/workflows:

on: [pull_request]

jobs:
  shell-check:
    runs-on: ubuntu-latest
    name: Shell Checker
    steps:
      - uses: actions/checkout@v2
      - uses: marounmaroun/shell-checker@v1
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          severity: 'info'
          exclude: ''

You can set the severity to one of: "error, warning, info, style". Default is "info".

You can also include type of warnings to exclude. For example:

exclude: 'SC2006,SC2148'

Default value is not set, meaning that there will be no exclusions.

Code is available here: https://github.com/MarounMaroun/shell-checker

What Does "\K" Mean in Regex?

Maroun Maroun — Mon, 20 Apr 2020 06:10:18 +0000

Since not all regex flavors support lookarounds, Perl introduced the match reset - \K (bolded is mine):

\K resets the starting point of the reported match. Any previously consumed characters are no longer included in the final match

To make the explanation short, consider the following simple Regex:

a\Kb

When "b" is matched, \K tells the Regex engine to pretend that the match attempt started at this position.

~$ echo 'hello world' | grep -oP 'hello \K(world)'
world
~$ echo 'hello world' | grep -oP 'hello (world)'
hello world

What Does "--" (Double-Dash) Mean?

Maroun Maroun — Thu, 19 Mar 2020 08:59:21 +0000

From man bash:

-- A -- signals the end of options and disables further option processing. Any arguments after the -- are treated as
filenames and arguments. An argument of - is equivalent to --.

In other words, -- is used to signify the end of command options. After it, only positional parameters are accepted.

For example, we want to look for the "--color" string using grep:

$ echo "hello --color" | grep --color
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
    [-e pattern] [-f file] [--binary-files=value] [--color=when]
    [--context[=num]] [--directories=action] [--label] [--line-buffered]
    [--null] [pattern] [file ...]

We got an error, since --color expect a value. We can fix by signaling the end of options to the grep command using --:

$ echo "hello --color" | grep -- --color
hello --color

It's important to note that not all bash builtin commands accept the -- as an end-of-options marker.

mycontribution - View Your Contribution Graph From the Terminal

Maroun Maroun — Tue, 17 Mar 2020 07:09:33 +0000

I wrote a script for fun, that brings your contribution graph to the terminal:

The code (GitHub link):

#!/bin/bash

username=$1
symbol=${2:-▣}
if [[ -z $username ]]; then
    echo "Usage: mycontribution <username>"
    exit 1
fi

declare -a months=("   J a n" "  F e b" "M a r" "  A p r" "   M a y" "  J u n" "   J u l" "     A u g" "   S e p" "     O c t" "  N o v" "    D e c")
currentMonth=`date +%-m`-1
months=("${months[@]:$currentMonth}" "${months[@]::$currentMonth}")

declare -a graph=($(curl -s https://github.com/"$username" | grep '<rect class="day"' | grep -oP '(?<=fill=").*?(?=" )'))

if [[ -z "$graph" ]]; then
    echo "User $username doesn't exist"
    exit 1
fi

# print months
echo
for month in "${months[@]}"
do
    printf "%s" "$month"
done

printf "   "
printf " %s" ${months[0]}

# print contribution graph
echo
i=0
while [[ "$i" -le 6 ]]; do
    for (( n="$i";n<${#graph[@]};n+=7 )); do
        if [[ "${graph[$n]}" == "#c6e48b" ]]; then
            printf "\\e[38;5;71m$symbol\\e[0m|"
        elif [[ "${graph[$n]}" == "#7bc96f" ]]; then
            printf "\\e[38;5;64m$symbol\\e[0m|"
        elif [[ "${graph[$n]}" == "#239a3b" ]]; then
            printf "\\e[38;5;22m$symbol\\e[0m|"
        elif [[ "${graph[$n]}" == "#196127" ]]; then
            printf "\\e[38;5;238m$symbol\\e[0m|"
        # no contribution
        elif [[ "${graph[$n]}" == "#ebedf0" ]]; then
            printf "\\e[38;5;252m$symbol\\e[0m|"
        fi
    done
    echo
    (( i++ ))
done
echo
printf "Less \\e[38;5;252m$symbol\\e[0m|\\e[38;5;71m$symbol\\e[0m|\\e[38;5;64m$symbol\\e[0m|\\e[38;5;22m$symbol\\e[0m|\\e[38;5;238m$symbol\\e[0m More"
echo

Enjoy :)

"Git checkouter" - A Simple Tool to Checkout, List or Rebase Your Git Projects

Maroun Maroun — Sun, 15 Mar 2020 07:51:36 +0000

The project is available on GitHub, on the following link.

git-checkouter is a tool that iterates on your parent Git folder, which includes all of your Git projects, and checkouts, lists, or rebase on top of master the given branch for each project.

What?

OK, it's a common practice to keep all of your work-related Git projects in some folder, let's say ~work:

.
├── project1
├── project2
├── project3
├── project4

Now you are working on a ticket "xxx", and you changed projects 1, 2 and 4.

Imagine you have many more projects, and you're working on many more tickets. Now you want to run local tests for the feature "xxx", but you don't remember what projects you have changed for this feature:

$ ./git-checkouter.sh -p ~/work -b xxx -d
'xxx' found in 'project1'
'xxx' found in 'project2'
'xxx' found in 'project4'

providing -d will only list which projects include the branch, and will not actually checkout.

It is also possible to set an environment variable: export PROJECTS_DIR=~/work and omit the -p flag.

After you saw which projects you changed for that specific feature, you can checkout the branch in all of them:

$ ./git-checkouter.sh -p ~/work -b xxx
project1: Switched to branch 'xxx'
project2: Switched to branch 'xxx'
project3: Switched to branch 'xxx'
project4: Switched to branch 'xxx'

If you want to ignore some projects, you can provide the -e flag:

$ ./git-checkouter.sh -p ~/work -b master -e project2,project3
project1: Switched to branch 'xxx'
Project excluded: project2
Project excluded: project3
project4: Switched to branch 'xxx'

Sync all branches with the remote master using the -f flag:

$ ./git-checkouter.sh -p ~/work -f
Rebasing project1: Current branch master is up to date.
Rebasing project2: Fast-forwarded xxx to origin/master.
Rebasing project3: Current branch xxx is up to date.
Rebasing project4: Current branch xxx is up to date.

The code:

#!/bin/bash

CYAN='\033[1;36m'
NC='\033[0m'
YELLOW='\033[0;33m'

display_usage() {
  echo "Usage: $(basename "$0") [OPTIONS]"
  echo ""
  echo "  -p  path to your projects' dir. If not provided,"
  echo "        will use env variable 'PROJECTS_DIR'"
  echo "  -b  git branch to checkout"
  echo "  -d  only print projects that have the given branch,"
  echo "        without actually check it out"
  echo "  -e  projects to exclude, separated by \",\" without spaces"
  echo "  -f  rebase all directories on top of remote master branch"
  echo ""
  echo "Bugs and suggestions: <https://github.com/MarounMaroun/git-checkouter/issues>"
  exit 1
}

projects=$PROJECTS_DIR
dry=''
branch=''
exclude=''
fetch=''

while getopts 'p:b:de:f' flag; do
  case "${flag}" in
    p)
      projects=${OPTARG}
      ;;
    b)
      branch=${OPTARG}
      ;;
    d)
      dry="true"
      ;;
    e)
      exclude=${OPTARG}
      ;;
    f)
      fetch="true"
      ;;
    *)
      display_usage
      exit 1
      ;;
  esac
done

if [[ (-z "$branch" || -z "$projects") && "$fetch" != true ]]; then
  echo "Error: both branch and projects dirs must be specified,"
  echo "unless you're using -f flag"
  echo ""
  display_usage
fi

if [[ ! -z "$exclude" ]]; then
  IFS=',' read -r exclude_projects <<< $exclude
fi

for d in $projects/*; do
  project_name=$(basename $d)
  if [[ ! -d "$d" ]]; then continue; fi
  cd $d
  if [ -d ".git" ]; then
    if [[ "$fetch" = true ]]; then
      printf "Rebasing branch ${CYAN}$(basename $d): ${NC}"
      git fetch && git rebase origin/master
      continue
    fi
    branches=$(git branch | cut -c 3-)
    branch_found=$(echo $branches | grep -oP "\b$branch\b")
    if [[ -z "$branch_found" ]]; then continue; fi
    if [[ ! -z "$dry" ]]; then
      printf "'$branch' found in ${CYAN}'$project_name'${NC}\n"
    else
      printf "${CYAN}$(basename $d): ${NC}"
      project_name=$(basename $d)
      if [[ $exclude_projects =~ .*$project_name.* ]]; then
        printf "${YELLOW}Project excluded:${NC} $project_name\n"
        continue
      fi
      git checkout $branch
    fi
  fi
done

Hello, K8s Spring Boot!

Maroun Maroun — Tue, 25 Feb 2020 08:50:23 +0000

Let's try to build the simplest Java Spring application that runs as a pod in a Kubernetes cluster.

The full project can be found on my GitHub.

The project's structure:

├── Dockerfile
├── README.md
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── k8s
│   └── depl.yaml
├── settings.gradle
└── src
    └── main
        └── java
            └── hello
                ├── App.java
                └── HelloWorldCtrl.java

App.java is our entry point:

package hello;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class App {

    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }

}

and our controller simply returns "hello world" on the root path:

package hello;

import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.RequestMapping;

@RestController
public class HelloWorldCtrl {

    @RequestMapping("/")
    public String index() {
        return "Greetings from Spring Boot!";
    }

}

Now let's write a Dockerfile:

FROM gradle:jdk10 as builder

COPY --chown=gradle:gradle . /app
WORKDIR /app
RUN gradle build

EXPOSE 8080
WORKDIR /app

CMD java -jar build/libs/gs-spring-boot-0.1.0.jar

It uses Gradle in order to build the application, and the CMD instruction runs the JAR file.

The K8s deployment is simple. It consists of a deployment and a service:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: hello-world
        visualize: "true"
    spec:
      containers:
      - name: hello-world-pod
        image: marounbassam/hello-spring
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  labels:
    visualize: "true"
  name: hello-world-service
spec:
  selector:
    app: hello-world
  ports:
  - name: http
    protocol: TCP
    port: 8080
    targetPort: 8080
  type: ClusterIP

The deployment defines two replicas of the pod that will be running the container that's built from the image specified in the image attribute.

The service is of type ClusterIP (the default Kubernetes service). It gives us a service inside our cluster that other apps can access.

Creating the resources in your cluster:

kubectl create -f <yaml_file>

The resources can be visualized as follows:

+---------------------+
| hello-world-service |
|                     |
|    10.15.242.210    |
+---------O-----------+
          |
          +-------------O--------------------------O
                        |                          |
              +---------O-----------+    +---------O-----------+
              |        pod 1        |    |        pod 2        |
              |                     |    |                     |
              |     hello-world     |    |     hello-world     |
              +---------------------+    +---------------------+

Inside The Cluster

If you're using minikube for running the cluster locally, you might encounter issues (I really don't know why). But if you're running on a cloud provider, or something more "serious" than minikube, you should be able to do the following:

$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
hello-world-5bb87c95-6h4kh   1/1       Running   0          7h
hello-world-5bb87c95-bz64v   1/1       Running   0          7h
$ kubectl get svc
NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
hello-world-service   ClusterIP   10.15.242.210   <none>        8080/TCP   5s
kubernetes            ClusterIP   10.15.240.1     <none>        443/TCP    7h
$ kubectl exec -it hello-world-5bb87c95-6h4kh bash
$ (inside the pod) curl 10.15.242.210:8080
$ (inside the pod) Greetings from Spring Boot!

If you have any questions, please drop a comment.

Job Control Commands in Linux

Maroun Maroun — Tue, 28 Jan 2020 20:08:02 +0000

Job is simply a process. In Linux, each job is associated with PID.

There are three types of jobs:

Foreground Jobs

When you run vi <file>, the vi program "occupies" the terminal window, and the process runs in the foreground.

When you exit the program, the application is no longer running, and the process dies.

Background Jobs

Processes that are running without occupying the window. This can be achieved, for example, by appending & at the end of the command. For example, when you run:

tar -czf file.tar.gz .

the tar process will block the terminal until it finishes. However, when you run:

tar -czf file.tar.gz . &

then it'll run in the background. And if you type jobs while it's still running:

jobs
[1]+  Running                 tar -czf file.tar.gz . &

Stopped Jobs

CTRL + z sends the SIGTSTP signal that stops the job that's runnin in the foreground.

Job Control Commands

jobs - lists all jobs
bg [PID...] - takes the specified job(s) to the background, resuming them if they are stopped.
fg [PID] - brings the specified job to the foreground, resuming it if it is stopped
CTRL + z - Sends the SIGTSTP signal that stops the running job

The following should demonstrate the commands above:

> tar -czf file.tar.gz .
# ...working...
# CTRL + z
Job 1, 'tar -czf file.tar.gz .' has stopped
> jobs
[1]+  Running                 tar -czf file.tar.gz . &
> fg %1 (or just "fg" since there's only one job)
# job restarts

That's all :)

Why Stack Overflow Is Part of My Daily Routine

Maroun Maroun — Sun, 26 Jan 2020 11:43:32 +0000

It is literally true that you can succeed best and quickest by helping others to succeed - Napoleon Hill

If you've ever been interested in programming or anything related to and been around the net long enough, you've come across Stack Overflow, accidentally or on purpose.

What is Stack Overflow?

Stack Overflow is a question and answer site for professional and enthusiast programmers. It's built and run by you as part of the Stack Exchange network of Q&A sites. With your help, we're working together to build a library of detailed answers to every question about programming

It was in 2013 when I asked my first question in Stack Overflow, got down-voted and my question was closed. Back then, I didn't know why was that 🤷‍♂️ all that I asked for was a solution for my homework, and by saying "solution" I mean a full solution. I didn't expect comments like:

You should solve your homework by yourself
What have you tried?
Be more detailed

It was an easy question for professional programmers who live in Stack Overflow, why are they being offensive?

After leaving the community, disappointed, for a couple of months, I decided to take another risk and ask another one. It was a practical and detailed question. Some senior members edited my question, fixed some typos and reformatted it, making it look much better.

Not only that I was up-voted, got a detailed answer, learned how to ask and got some points, but I was also encouraged and informed that I was really close to the solution.

I began visiting Stack Overflow on a daily basis, just to check if my question has new answers or comments. While hanging out there, I saw a very similar question to mine, I knew the answer! But just before I posted it, I had to verify it's good by opening my IDE, running the code and validating it - By doing so, I was more confident about the subject being discussed and I better understood the problem!

Knowledge has to be improved, challenged, and increased constantly, or it vanishes - Peter Drucker

By navigating through Stach Overflow, I get exposed to new fields and keep atop new technologies, I can choose what subjects I'm interested in and filter questions accordingly.

Every day I learn something new through reading more posts from users. Sometimes I find myself investigating questions that I came across because I was curious about, I challenge myself to find a solution to that problem. By doing this, I do research, I try new things, I dive into other fields and not only that I'm helping the original poster, but I'm learning new things. I can get comments to my answers and improve them, I can comment on answers, edit answers and questions, vote on them and more.

Stack Overflow is the place for programming questions, it's an endless source of knowledge, use it.

Meet "gh" - the Official GitHub CLI

Maroun Maroun — Tue, 21 Jan 2020 07:34:50 +0000

gh is a new CLI that enables you to work seamlessly with GitHub on the command line.

As of the date of writing this post, the tool is still in its early stages of development.

Installation

brew install github/gh/gh

Features

With gh, you can create, view, and checkout pull-requests. You can also create and view issues. Let's view its options:

$ gh pr create --help
Create a pull request

Usage:
  gh pr create [flags]

Flags:
  -B, --base string    The branch into which you want your code merged
  -b, --body string    Supply a body. Will prompt for one otherwise.
  -d, --draft          Mark pull request as a draft
  -t, --title string   Supply a title. Will prompt for one otherwise.
  -w, --web            Open the web browser to create a pull request

Global Flags:
      --help              Show help for command
  -R, --repo OWNER/REPO   Select another repository using the OWNER/REPO format

Now let's create a simple PR:

$ gh pr create --base master

Creating pull request for test_branch into master in MarounMaroun/git_examples

We'll now be prompted to enter the PR title:

$ gh pr create --base master

Creating pull request for test_branch into master in MarounMaroun/git_examples

? Title My first PR from CLI!

Continuing with the prompt, we'll be asked to enter the PR's description, and finally a validation window:

? Submit?  [Use arrows to move, type to filter]
> Yes
  Edit
  Cancel

After hitting "Yes", the PR will be created for us:

Feel free to explore the command:

gh --help
gh pr --help
gh pr create --help
gh issue view --help
# and so on...