Home Tutorials Training Consulting Books Company Contact us


Get more...

Git typical workflows. This tutorial explains typical workflows for using Git.

Learn more in the Learning Portal. Check out our
Git Online Training High Priority

1. Typical Git workflows

The following description highlights typical Git workflows.

1.1. Using pull requests for repositories without direct write access

The most popular Git workflow is the usage of pull requests. In this workflow a developer uses a server side functionality to request that commits from a branch (from the same or another repository) are integrated into another branch (in the same or another repository). Automatic checks can be added to verify the changes and a manual review can be performed.

A pull request can be seen as a notification which includes the information from which branch and URL the changes can be pulled. It also contains the information into which URL and branch these changes should be integrated.

If the user has write access to the repository, he still can create pull requests from one branch to another branches, typically the main development branch. If the user does not have write access, but can create a clone, he can clone the repository, push commits to his clone and can send the owner a pull request asking to integrate these commits.

You can use the git request-pull command to generate a generic pull request which you may include into an email. See Git request-pull for details.

1.2. A shared repository between developers

A very typical Git workflow is that the developers integrate their work via a shared remote repository. The shared repository is located on a server so that it can easily be reached by each developer. The initial setup requires that every developer clones the remote repository or adds the remote repository as additional remote to his local repository.

Developers typically use different remote branches for shared feature developments or maintenance work.

To develop a change and integrate it into the shared repository, the developer would typically:

  • Create a new local branch or use an existing local branch

  • Change content in the working tree, stage and commit his changes

  • Once the development in the branch is complete he could either:

    • Push to the remote branch and create a pull request for the main development branch

    • Either: Rebase his branch onto the relevant remote-tracking branch to allow a fast-forward merge on the server and afterwards he pushes his work to the target remote branch

    • Or Merge with the relevant remote-tracking branch

Typically developers use the remote master or main branch on the remote repository to integrate their work. At any point the developer can switch to a new local branch to work on a different topic.

During this development he may fetch and merge or rebase the changes from the remote repository at any point in time. The developer may use the pull command instead of the fetch command.

Using a pull request (merge request) to integrate your work is recommended as this allows build servers to validate your change before integration and other developers can review your changes if desired.

1.3. Working with two repositories

Sometimes you want to add a second remote repository to your local Git repository and pull from and push to both repositories. The following example describes how to add another remote repository and exchange commits with both repositories.

You can add another remote repository called remote_name via the following command.

# add remote
# syntax: git remote add <remote_name> <url_of_gitrepo>
# git remote add mysecondrepo <url_of_gitrepo>

git remote -v
# see all repos

For merging the changes in mysecondrepo create a new branch called newbranch.

# create a new branch which will be used
# to merge changes coming from repository 1
git checkout -b <newbranch>

Afterwards you can pull from your new repository called mysecondrepo and push to your original repository, e.g., origin.

# reminder: your active branch is newbranch

# pull remote_name and merge
git pull mysecondrepo

# or fetch and merge in two steps
git fetch mysecondrepo
git merge mysecondrepo/newbranch

# afterwards push to first repository
# -u sets the tracking branch
# for the current branch
git push -u origin master

1.4. Providing a patch

Git emphasizes the creation of branches for feature development or to create bug fixes. The following description lists a typical Git workflow for fixing a bug in your source code (files) and providing a patch for it. This patch contains the changes and can be used by another person to apply the changes to his local Git repository.

This description assumes that the developer who creates the changes cannot push changes directly to the remote repository. For example you solve an issue in the source code of an open source project and want the maintainer of the project to integrate this change in the official repository.

  1. Clone the repository, in case you have not done that before

  2. Create a new branch for the bug fix

  3. Modify the files (source code)

  4. Commit changes to your branch

  5. Create patch

  6. Send patch to another person or attach it to a bug report, so that it can be applied to the other Git repository

You may also want to commit several times during 3. and 4. and rebase your commits afterwards.

if you are using the Eclipse IDE, its patch support currently has a bug, see https://github.com/eclipse-platform/eclipse.platform.team/issues/15

2. Links and Literature

Git homepage

EGit - Teamprovider for Eclipse

Video with Linus Torvalds on Git

Git on Windows

2.1. vogella Java example code

If you need more assistance we offer Online Training and Onsite training as well as consulting

See License for license information.

Legal Privacy Policy Change consent