Essential Git commands

Git is a distributed Version Control System (VCS) also called a Revision Control System (RCS). Every Git directory, on any computer, is a real repository, with code history and version-tracking capabilities.

Much of the software development with Git has been done using the GitHub platform, which has its own implementation of Git and offers gratis and paid accounts that one can use to host software repositories and interract with them remotely. Unfortunately, GitHub has been acquired by Microsoft in 2018 and many developers who value their independence moved their repositories from github.com to self-hosted GitHub alternatives. The important thing to note, is that working with Git doesn’t imply using GitHub. A programmer can install Git and an application that imitates GitHub’s web interface on her/his own server, and can use them to track code revisions, collaborate with other programmers, etc., just like when (s)he used GitHub.

Git can be also used in command line, without any web interface. The commands listed below will be run in a terminal, to interact with local or remote software repositories.

Install git if necessary

Check if git is already installed on the system:

git --version

If it is installed, the output will be:

git version x.y.z

If it’s not installed, you can install it with apt-get install git .

Set the identity of the committer

The first step is to set the name and email address that will be associated with the Git commits, merges, etc. of the current logged in Linux user:

git config --global --edit

The ~/.gitconfig file will be opened. Here add the following lines below [user]:

name = username
email = user@example.com

Replace username with the name that you want to be associated with your Git operations and user@example.com with the email address that will be associated with your Git operations.

Create a Git repository

To create a Git repository, navigate to the directory where you want to place the repository and create a new directory (here we’ll call it projectname), then switch to it:

cd /path/to/location
mkdir projectname
cd projectname

Then transform projectname into an empty Git repository and configure it to allow group access, by running:

git init

This command will create the hidden directory .git inside projectname, which will contain important information about the current repository: revision history, various configrations, etc. Please note that if you want to allow remote users to push code to the new repository, you will want to run the git init command in the following form:

git init --shared=group

In this manner, you can set a specific group as the owner of the repository, then add users to that group in order to allow them to push code remotely to that repository. Further down below is an example of how to set such ownership and permissions.

Next, copy all the files and directories that you want to store in the repository, to the projectname directory and run:

git add -A

This will add all the files inside the projectname directory and its subdirectories to the new repository, so that they will be tracked for revisions by Git. After adding the files, you have to commit the change by running:

git commit -m "Created a new repository"

Replace Created a new repository with a short message describing the commit.

If you want to transform an already existing directory with all its content, into a Git repository, just navigate to it, run git init --shared=group , then git add -A , then git commit -m "new message" .

Another method to create a local Git repository is to clone a remote repository. Cloning a repository means to get a copy of that repository on your machine. To clone a remote repository over HTTP, run:

git clone https://example.com/subdir/projectname

where https://example.com/subdir/projectname is the ‘cloning’ URL that the remote party has to provide. projectname can have the git termination (projectname.git), but it’s not required. To allow repository cloning over HTTP, a host has to have a web server configured for this purpose.

If you want to clone a specific branch of a remote repository, run:

git clone -b branch-name https://example.com/subdir/projectname

To clone a remote repository over SSH, run:

git clone ssh://username@example.com:6354/path/to/location/projectname

where 6354 is the custom SSH port. ssh://username@example.com:6354/path/to/location/projectname is the URL that the remote party has to provide, to allow cloning over SSH. Please note that if the SSH port is the default port 22, the cloning URL can have a different syntax, and the command for cloning will become:

git clone username@example.com:subdir/projectname

If you set up a Git repository and you want to allow remote users to clone it, in general, it’s better to allow cloning over HTTP and not over SSH, because to clone over HTTP, a remote user doesn’t need SSH access to your machine, knowing that SSH access can involve security risks.

Set the right ownership and permissions for a Git repository

After a repository is created, it’s recommended to create a new group (by running addgroup groupname) and change the ownership and permissions for the repository, so that new remote users can be easily allowed to ‘push’ code to it. You can set the following ownership and permissions for the projectname repository:

chown -R www-data:groupname /path/to/location/projectname
find /path/to/location/projectname -type d -exec chmod 2770 {} +
find /path/to/location/projectname -type f -exec chmod 660 {} +

With these settings, when you want to allow a new remote user to ‘push’ code to the projectname repository over HTTP, you first add the new user on the system (without shell access and without a home directory):

adduser --shell /bin/false --no-create-home username

then you add the user to the groupname group:

adduser username groupname

then you create a basic HTTP authentication user and password for the new user:

htpasswd /etc/nginx/htpass/git-users username

and configure the web server so that only the users with the correct HTTP authentication credentials are allowed to ‘push’ code to the projectname repository.

Create a new branch

A branch is a copy of the files of a repository, at the time the branch is created. Branches allow developers to work simultaneously on the same project without affecting one another. When work on a branch is finished and the changes can be added to the main codebase, that branch can be merged into the default branch. By default, when a new Git repository is created with the git init command, a branch called master is also created. When you work on that repository, if you don’t create other branches, you will work on the default master branch.

To create a new branch run:

git checkout -b newbranch

where newbranch is the name of the new branch, which should be a string containing only lowercase letters, numbers, hyphens (-), underscores (_) or dots (.).

When you create a new branch, by default, the new branch will be a copy of the branch you are currently on. If you want to create a new branch based on a different branch than the current branch, run:

git checkout -b newbranch existingbranch

where newbranch is the name of the new branch and existingbranch is the name of the existing branch that you want to copy as a new branch.

Delete a branch

To delete a branch called branch, switch to a different branch, then run:

git branch -d branch

Add files to the current branch

Once you switch to a repository branch with the git checkout branch command, you can add files to it, by running:

git add filename1 filename2 filename3

git commit -m "new commit short description"

With the git add command you stage the changes, and with the git commit command you commit the changes. You can add directories using the same commands. If the files are not located in the working directory, replace their names with the paths to their location, relative to the working directory. Please note that you cannot add an empty directory. To add a directory, it has to contain at least a file. If it doesn’t, you can create a hidden empty file called .gitignore inside it, to allow adding the directory to the repository.

It is recommended to add to any repository a README.md file (a text file using the ‘Markdown’ syntax) to describe the content of the repository.

Add an entire directory to the current branch

git add /path/to/directory/\*

git commit -m "new commit description"

Add all the new and changed files from the repository root directory and its subdirectories to the current branch

git add -A

This command stages all those files that are new or are changed and are not ignored, in the entire root directory of the repository and its subdirectories. To commit the changes, run:

git commit -m "commit description"

git add -A is equivalent with git add --all.

Stage all the files with changes in the root directory and commit the changes in one command

git commit -am "commit description"

Remove files from the current branch

To remove files from the current repository branch, run:

git rm filename1 filename2 filename3

git commit -m "new commit description"

The command git rm filename removes the file from the index of tracked files and also removes it from the hard drive. If you remove a file by running rm filename directly, to remove the file from the index of tracked files and keep the branch in good condition, you will need to also run git rm filename followed by git commit -m "commit message".

Remove an entire directory and its content from the git index and from the hard drive

git rm -r /path/to/directory

git commit -m "new commit description"

Add an entire directory to git index

git add /path/to/directory/\*

Switch between branches

If you want to work on a branch, you can switch to it by running:

git checkout branch

List local branches

git branch

If you want to see the local branches together with the last commit on each, add the -v (verbose) option, like this:

git branch -v

Please note that if you clone a remote repository with multiple branches with the git clone command, only the remote branch currently checked out in the remote repository will be transferred, so that it can be listed locally with the git branch command. If you want to fetch the content of another remote branch and make it available locally, you can checkout a local branch with the same name as the remote branch:

git checkout remote-branch

List remote branches

git branch -r

List local and remote branches

git branch -a

Check the status of the current branch

To find what is the current branch, if there are uncommitted changes or failed operations for the current branch, run:

git status

List the differences between two branches

git diff branch1..branch2

List all the unstaged (and uncommitted) changes

git diff

List all the staged (but uncommitted) changes

git diff --staged

List the detailed history of commits, for the current branch

git log -p

List the detailed history of commits for a specific file

git log -p filename

List the detailed commits for a specific file, by a particular author

git log --author="Author Name" -p filename

List the history of commits for the current branch, one commit per line

git log --oneline

Reapply commits on current branch on top of commits imported from another branch, with the ‘git rebase’ command

Let’s suppose you work on the branch ‘develop’ where you add 4 commits, then you create a branch called ‘contrib’, which will have the exact 4 commits of the ‘develop’ branch. Next, you add 3 more commits on the branch ‘develop’, then you switch to the branch ‘contrib’:

git checkout contrib

and add 5 more commits here. Now you want to bring the 3 new commits from ‘develop’ into ‘contrib’, and add them before the 5 new commits on ‘contrib’, to maintain the project’s history. To achieve this, while your current branch is ‘contrib’, run:

git rebase develop

This command will bring the 3 new commits from ‘develop’ and apply then after the first 4 commits in ‘contrib’, then, it will reapply the 5 new commits of ‘contrib’ on top of everything, avoiding to add any change multiple times. So, if a change has been made in the imported commits, it will not be made again with the reapplied commits.

Merge two branches

git checkout branch-to-merge-into

git merge branch-to-be-merged

When you try to merge two branches, there can be conflicts between them and you will have to solve the conflicts to be able to complete the merge. Conflicts usually arise when there are overlaping changes in the same file, so that transferring the changes from one branch will remove the changes on the other branch. In this case, Git will signal the conflict and will show which is the problematic file. Usually, these conflicts can be solved by manually editing the file to bring it to the desired form, then staging it with git add filename, then committing the changes with git commit -m "commit description". This completes the merge, if there are no other problems.

When a Git operation such as a merge encounters conflicts, the branch can enter in a so-called ‘detached HEAD’ state. The HEAD is a pointer to the last commit. When merges or other operations fail, the HEAD can become detached from the tip of the branch and in this state, if you make changes, they won’t be associated with any branch. This is why the ‘detached HEAD’ state should be avoided by solving the conflicts and completing the operations.

Please note that after you manually solve a merge conflict as explained above, if you try to delete the branch into which you merged (here we called it branch-to-merge-into), you may receive the warning:

error: The branch 'branch-to-merge-into' is not fully merged.
If you are sure you want to delete it, run 'git branch -D branch-to-merge-into'.

This is caused by the fact that the changes in branch-to-be-merged are not all present in branch-to-merge-into, although the two branches were merged, because you manually changed the conflicting file and made it look different than in branch-to-be-merged. When you receive this warning after manually solving a merge conflict as explained above, you can just use the suggested command to delete the branch:

git branch -D branch-to-merge-into

Continue a rebase or merge operation that has stopped because of a conflict

If you run git merge branchname or git rebase branchname and the operation stops because of a conflict, after you solve the conflict by manually editing the conflicting file(s), you can conclude the merge/rebase operation by running:

git merge --continue

or

git rebase --continue

If you want to abort a merge/rebase operation, you can do it with:

git merge --abort

or

git rebase --abort

Add a ‘remote’ for the current branch, that allows pushing code over HTTP

git remote add remotename https://username:password@example.com/git/projectname/

where remotename is the ‘remote’: a local name of the remote repository (usually ‘origin’ is chosen as the local name of the remote repository, but it can be any other name), and https://username:password@example.com/git/projectname/ is the URL provided by the maintainer of that remote repository, that allows remote users with the right credentials to push code over HTTP. The URL of the ‘remote’ can be added without a username and password (like this: https://example.com/git/projectname/), but in this case, eath time the user will try to push code to the remote repository, he will be asked for his username and password.

Code can be pushed over SSH also, but this would imply that the remote users have SSH access to the server hosting the repository, and this will add security risks. The command to add a ‘remote’ to allow pushing code over SSH will be:

git remote add remotename ssh://username@example.com:6354/path/to/location/projectname

where username is the name of the remote user with SSH access (his password will be required right after running the command), 6354 is the custom SSH port, and projectname is the remote repository.

When you create a local clone of a remote repository with the git clone URL command, the ‘remote’ for the local clone will be automatically called ‘origin’ (you can find its name in the .git/config file; the .git directory is located in the root directory of the local repository) and the URL used for cloning will be set as the URL of the ‘remote’. If you want to change the name or the URL of the ‘remote’, you will have to first remove the ‘remote’, as shown below, and then add a new ‘remote’.

Remove the ‘remote’ for the local repository

git remote rm remotename

List the remote repository with details

git remote -v

Push code to a remote repository

To transfer all the new changes made on a local branch to the corresponding remote branch (which usually has the same name), use the push command, like this:

git push remotename local-branch

You can also use:

git push

to push the changes from the current local branch to the corresponding remote branch from the configured ‘remote’.

If you push changes adding the -u option (the short version of the --set-upstream option) like this:

git push -u remotename local-branch

the branch with the same name as the local branch, in the remote repository (indicated by remotename) will be set as the ‘upstream branch’ of the local branch. This will make any subsequent commands without arguments (like git push or git pull), use that remote branch for that operation. If you don’t have an ‘upstream branch’ set up for a local branch and you run git push without arguments, Git will not know where to push the data and will generate the following error message:

fatal: The current branch develop has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream remotename develop

where develop is the current local branch and remotename is the configured ‘remote’.

If you clone a remote repository with multiple branches with git clone, when you checkout a local branch with the same name as one of the remote branches (with git checkout remote-branch), the content of the remote branch will be pulled into a local branch with the same name. Also, the remote branch will be set up automatically as the ‘upstream branch’ for the local branch. Therefore, in these situations, you won’t have to set up ‘upstream branches’ for local branches manually.

You can also set a remote branch as the ‘upstream branch’ of the current local branch by running:

git branch -u remotename/remote-branch

Please note that if you create a local branch that doesn’t exist in the remote repository and you push data from this local branch to the configured ‘remote’, the new branch will be created in the remote repository. In this situation, you will have to set up manually the remote branch as the ‘upstream branch’ of the local branch, if you want to run commands without arguments, like git push, git pull, etc.

Force pushing code to a remote repository

git push --force remotename local-branch

Fetch a branch from the ‘remote’

git fetch remotename remote-branch

This command only fetches the information about the remote branch. After running this command, to pull the content of the remote branch, checkout a local branch with the same name as the remote branch:

git checkout remote-branch

This command will pull the content of the remote branch into a local branch with the same name and it will set the remote branch as the ‘upstream branch’ of the local branch.

Fetch all branches from the ‘remote’

git fetch remotename

This command only fetches the information about all the remote branches. After running it, to pull the content of a specific remote branch, checkout a local branch with the same name as the remote branch:

git checkout remote-branch

This command will pull the content of the remote branch into a local branch with the same name and it will set the remote branch as the ‘upstream branch’ of the local branch.

Fetch commits from a remote branch and merge them into the current branch

If you want to review the changes made to a remote branch before merging them into the current branch, you can fetch all the changes from the remote branch, without merging them, by running:

git fetch remotename remote-branch

Then, to see the changes made on the remote branch that you don’t have on the corresponding local branch, run:

git log -p local-branch..remotename/remote-branch

Then, if you want to integrate the remote changes into the current branch, merge them by running:

git merge remotename/remote-branch

Please note that the two operations, fetch and merge, can be done with one command: pull, as shown below. Using pull however, will not allow seeing the changes from the remote branch before merging them.

Pull code from a remote repository

To fetch and merge the changes made on a remote branch that you don’t have on the corresponding local branch, use the pull command like this:

git pull remotename local-branch

or simply

git pull

to pull the changes from the configured ‘remote’ to the current local branch.

Delete a remote branch

git push remotename --delete remote-branch

Add tags to commits

A tag is a label used to mark a particular commit. Tags are often used for marking the releases of software projects. Simple tags that are just pointers to specific commits are called ‘lightweight tags’, and tags with meta-data that contain a description and can be digitally signed are called ‘annotated tags’. To create a lightweight tag for the last commit, run:

git tag tag-name

To create an annotated tag for the last commit, run:

git tag -a tag-name -m "This is the latest version."

where This is the latest version. is the description associated with the tag.

To add a lightweight tag for a specific commit, you have to first find the commit’s name (the first 7 characters of its hash code) using a command like git log, then run:

git tag tag-name 6c4ad9e

where 6c4ad9e is the commit’s name.

To add an annotated tag for a specific commit, run:

git tag -a tag-name -m "New version with changed scripts." 5a2eb4d

where 5a2eb4d is the commit’s name.

List existing tags for the current branch

git tag

Push tags to a remote repository

By default, the git push command doesn’t transfer tags to the remote repository. Therefore, if you want to have them transferred to the remote repository, you have to push all the tags explicitly like this:

git push remotename --tags

or you can push just a specific tag, by running:

git push remotename tag-name

Delete a local tag

git tag -d tag-name

Delete a remote tag

git push remotename --delete tag-name

Discard all unstaged and uncommitted changes made to a file

git checkout -- filename

If the file filename is not located in the directory in which you run the command, replace filename with the path of the file, relative to the current directory.

Discard all unstaged and uncommitted changes made to all tracked files (on all branches)

git checkout .

Discard all staged but uncommitted changes to a file

git reset filename

Please note that this command will ‘unstage’ the changes to the specified file, which means that it will undo the git add filename command, but the file will remain changed. Therefore, when you will run git status, you will see a message informing you that filename has been changed but the changes haven’t been committed. To discard the changes made to filename and make that message dissapear, you can run git checkout -- filename .

Discard all staged but uncommitted changes to all tracked files

git reset

Please note that this command will ‘unstage’ the changes to all tracked files, but the changed files will remain changed. Therefore, when you will run git status, you will see a message informing you that there are uncommitted changes. To discard the changes made to all the tracked files and make that message dissapear, you can run git checkout . .

Discard all changes since the last commit

If you made any changes to any files and staged the files (with git add filename) or didn’t stage the files, you can remove all the changes since the last commit by running:

git reset --hard

Discard all changes after a specific commit

If you want to remove all the changes made after a specific commit, run:

git reset --hard 5b4e6cd

where 5b4e6cd is the commit name (the first 7 characters from the commit’s hash code).

If you pushed your changes after commit 5b4e6cd to the remote branch before discarding them on the local branch, to also discard them on the remote branch, run:

git push --force remotename local-branch

Discard the last 3 commits on the current branch

git reset --hard HEAD~3

Undo the changes introduced by a commit, using the ‘git revert’ command

If you want to undo the changes introduced by a specific commit without discarding any commit, you can use the git revert command. This command adds a new commit that undoes the changes done with the specified commit:

git revert 2c4f6d9

where 2c4f6d9 is the commit name (the first 7 characters from the commit’s hash code). Please note that this command usually signals conflicts that have to be solved manually, if the file changed by the specified commit (2c4f6d9) was changed by other subsequent commits.

Squash multiple commits

If you want to compress multiple commits into one, in order to obtain a cleaner history, you can ‘squash’ the commits. For example, if you have 5 recent commits and you want to squash them into one single commit, run:

git rebase -i HEAD~5

The -i option runs the rebase command interactively. A new screen will open, showing a list with the last 5 commits, each on a new line starting with the term pick. Leave pick for the commit that you want to preserve, and change pick to squash for the commits that you want to squash (the commits are listed from the oldest at the top to the newest at the bottom); save and exit, then, in the new screen, update the commit message (you can delete the original commit messages for the 5 commits and replace them with one message on a single line), then, if you want to update the remote repository, run:

git push --force remotename local-branch

Exclude files and directories from being tracked by Git

To exclude files or directories from the files and directories tracked by Git, you can store their paths, one per line, in a file called .gitignore, saved in the root directory of the repository. Directory paths must end with a slash. Example:

path/to/filename1
differentpath/to/filename2
another/path/to/directory/

All the paths must be relative to the root directory of the repository.

Get information about a Git command

git command --help

Please note that the Git command git request-pull doesn’t have the same function as a GitHub ‘pull request’. The git request-pull command doesn’t make a ‘pull request’. It just generates a summary of the changes made on the local branch, that can be copied and sent by email to the project maintainer, to inform him about the local changes, that can be then merged into the project.

Creating ‘pull requests’ on GitHub

If a software project is still hosted on GitHub because its maintainers didn’t want to move it to a self-hosted alternative, and you want to contribute code to such a project, you will have to submit a ‘pull request’ to that project’s GitHub repository. Below is a presentation of the steps to follow if you want to create a ‘pull request’ on GitHub. We will explain how to interact with GitHub repositories over HTTPS.

Please note that instead of connecting to GitHub over HTTPS to clone/push/fetch, etc., you can connect via SSH. However, to use the SSH method, as explained in the official GitHub documentation, you will need to first generate a SSH key and protect it with a strong passphrase, save the public key in your GitHub account, then, to avoid having to enter the passphrase for every interaction with a GitHub repository, you will want to add your SSH key to ssh-agent on your local computer, and configure your machine to automatically load all your keys after reboot, as explained here.

Create a ‘personal access token‘

GitHub changed their platform so that users working in command line cannot interact with GitHub repositories by using their GitHub username and password. Instead, they have to use a ‘personal access token’. We explain below how to create and use this token:

1. Sign in to your GitHub account, click your user picture in the upper right corner, then click ‘Settings’.

2. On the left sidebar, click ‘Developer settings’, then on the new left sidebar click ‘Personal access tokens’.

3. Click the ‘Generate new token’ button.

4. In the ‘Note’ text box enter a descriptive name for the new token.

5. Under ‘Expiration’ select an expiration period.

6. Under ‘Select scopes’, select the scopes/permissions that you would like to grant this token. A good list of permissions would be: repo, workflow, write:packages, delete:packages, admin:repo_hook, gist, notifications, delete_repo, write:discussion.

7. Click the ‘Generate token’ button.

8. Copy your personal access token to a safe location. After you navigate away from that page, you won’t be able to see the token again. (To store passwords and passphrases securely, you can use the free and open source application KeePassX.)

Once you have a personal access token, you can enter it instead of your password in command line, when performing Git operations over HTTPS. It can be also used to authenticate to GitHub’s API.

For example, to push local changes to your GitHub repository over HTTPS, you will run:

git push origin local-branch
Username: your_username
Password: your_personal_access_token

origin is the default name of the ‘remote’. If you changed it to something else, use the new name instead of origin.

Instead of entering your personal access token manually for every Git operation over HTTPS, you can use Git’s credential helper, which will cache the token in memory for a period of time that you can specify. To use the Git credential helper, you will need to have Git version 1.7.10 or newer.

If you turn on the Git credential helper, by default, Git will cache your token in memory for 15 minutes. To turn on the credential helper, run:

git config --global credential.helper cache

To change the default caching period and make Git cache your token for one hour (3600 seconds), run:

git config --global credential.helper 'cache --timeout=3600'

Create a GitHub fork

1. Sign in to your GitHub account, then open the GitHub repository that you want to fork in a separate tab of the same browser.

2. Click ‘Fork’ in the upper right corner of your screen to create your own version of the repository.

Clone the GitHub fork on your local machine

To clone your forked repository on your local computer, go to your GitHub overview page, click on the name of the fork that you have just created, then click on the ‘Code’ button, then, under ‘Clone’, click on ‘HTTPS’ and copy to your clipboard the cloning URL. To clone the repository to your local machine, run the following command:

git clone https://github.com/your-username/projectname.git

This will create a local copy of your forked repository and you will be able to work with it as with any other Git repository, using all the Git commands presented above.

Create a local branch

Once you’ve cloned the forked repository on your local machine, create a local branch, based on the branch from the original repository that you want to contribute to. Very rarely GitHub repositories contain only the master branch. Usually, they contain several branches and you should pick the branch to which you want to send your changes. The branch to which you want to apply your changes can be master, develop, contrib, v1.0.0, etc.:

git checkout -b new-branch branch-to-change

This command will make a copy of the branch-to-change, which is the branch from the original repository to which you want to send your changes. Therefore, you will make all your changes to new-branch, then you will push that branch from your computer to your GitHub forked repository, then you will make a pull request for new-branch against the branch-to-change from the original repository.

You can verify that you are on new-branch with the git status command.

After you add a new file, or edit an existing file, you can stage it with:

git add filename

If the file is not located in the working directory, replace filename with the path to the file, relative to the working directory. Next, commit the change with:

git commit -m "short commit description"

Of course, you can stage all the new files and all the files with changes by running git add -A , then commit the changes with git commit -m "commit description".

Push your changes to GitHub

After you make all the desired changes on your local branch, which we called new-branch, push your local branch to GitHub, by running:

git push origin new-branch

origin is the default name of the ‘remote’. If you changed it to something else, use the new name instead of origin. Since you haven’t created a remote branch with the same name as the local branch, this command will automatically create it in your GitHub repository.

Submit a pull request on GitHub

1. On your GitHub overview page click on the name of your forked repository.

2. Use the ‘Switch branch’ drop-down menu to select the branch containing your changes (in this presentation we called it new-branch).

3. Click ‘Contribute’ (on the bar located right above the list of folders and files of the repository), then click the ‘Open pull request’ button.

4. On the ‘Open a pull request’ page, you will see the name of the repository and branch to which you want to submit your pull request, on the left, and the name of the repository and branch from which you want to submit the pull request on the right. Make sure that you create the pull request properly, from the branch that you changed to the original branch that you want to contribute to. The repositories and branches should look like this:

base repository: name-of-original-repository  base: name-of-branch-you-want-to-contribute-to      head repository: name-of-your-forked-repository  compare: name-of-your-branch-containing-your-changes

In our example, we called the branch containing your changes new-branch.

Enter the title of your pull request in the title text box, enter a brief description in the ‘Write’ text area, then click the ‘Create pull request’ button.

Create a GitHub pull request using only the web interface

If you want to submit a pull request with only a few changes, it can be more practical to add/edit the files directly in the browser, in your GitHub account. So, you can add/edit files and create a pull request using the web interface exclusively. You can learn how to do this here.

It’s worth mentioning that instead of using the command line to perform Git operations, some developers like to use GUI Git clients, that they install on their local computers.