Steps of the Integration Manager Workflow
This section describes steps of Integration Manger Workflow.
Forking
You start the workflow by making your public developer fork. To achieve this, just navigate to the blessed repository, click Fork in the action bar and enter a meaningful name and some description for your fork.
You can now clone your public developer fork to a local developer private instance like:
git clone <clone-url-of-your-developer-public>
For Mercurial:
hg clone <clone-url-of-your-developer-public>
Start making changes in this clone, commit and push them back to your serverside fork. You will see the changes popping up in the Changes tab of your developer public.
Sending Pull Requests
When you reach a point where you want to send your changes back to the blessed repository, navigate to your developer public and click Send Pull Request. This typically happens when a story resulting in multiple changes is completed: a feature is implemented, a bug is fixed and so on.
Codebeamer will now show you the changes you've made since the last merge with the blessed repository. This is the set of changes that you offer for the integrator to bring to blessed repository.
You can give a summary and some description where you explain what is the reason behind the changes, what you actually did, whether it's a risky change to merge, and so on. You can also choose which other users to involve in the integration workflow
It is recommended to pull requests to multiple integrators.
Viewing Pull Requests
Pull requests are listed in the Pull Requests tab of their target repositories. You can filter them by status and then browse through the lists easily. The count of pending pull requests is also shown in the repository cards, as this is considered as a very important piece of information.
Accepting and Rejecting Pull Requests
After the pull request is sent, integrators will be notified via email. They can review and discuss the proposed change by commenting on it. A pull request discussion like this is perfect for a quick peer code review.
They can then decide whether to accept (and merge) or reject the changes. If the submitter changes his mind, he has the chance to revoke the pull request, too.
When integrators decide to accept the proposed changes, they can do the following two things:
1. If there are no merge conflict introduced by accepting the change, they can merge it by clicking Merge in the web interface.
2. If there are merge conflicts, Codebeamer allows resolving the conflict by manual merging.
See both situations in details in the following sections.
Closing Pull Requests by Web-based Merging
If the pull request can be merged without conflicts, then you can simply click Merge and the contributed changes will be automatically merged into the upstream repository and the status of the pull request will be set to completed.
(This only updates the repositories on your Codebeamer server. To see the fresh state in your local environment, you have to pull everything to your local clone.)
With the changes merged into blessed, the workflow has been completed.
Closing Pull Requests by Manually Resolving Merge Conflicts
Sometimes a pull request can't be automatically merged. In most of the cases, it happens simply when two users modified the same line of the same file concurrently. In this situation, Git obviously can't decide which changes is the correct one. Git will detect the conflict, then lets you to manually resolve it.
First, you will have to pull in the changes from the fork:
git pull <name-of-the-remote-that-points-to-the-fork> master
Read the next section about
configuring remotes if you are not familiar with this
If you want to fetch from the fork only up to a given changeset just use the following two commands instead of
git pull
git checkout master
git fetch <name-of-the-remote-that-points-to-the-fork> master
git merge <the-last-changeset-id-to-be-merged>
With Mercurial:
hg pull -u <symbolic-name-that-points-to-the-fork>
hg merge
(Please learn more about
configuring symbolic names in hgrc if you don't know how to do that.)
As a result of the pull, Git will list the files with conflicts. Open the conflicting files in your favorite editor and resolve the changes. After this, you can commit and push everything back to the server:
git commit -a -m Manually resolving conflicts
git push
With Mercurial you have to mark all the conflicting files as resolved:
hg resolve -m <file-name>
Then you can commit:
hg commit -m Manually resolving conflicts
hg push
Codebeamer will automatically detect if there is a pending pull request related to this set of changes. If so, then it will change its status to completed without any further user interaction.