Git typical workflows. This tutorial explains typical workflows for using Git.
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
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
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
|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.
Clone the repository, in case you have not done that before
Create a new branch for the bug fix
Modify the files (source code)
Commit changes to your branch
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
If you need more assistance we offer Online Training and Onsite training as well as consulting