Before you start you should setup your development environment and read the guidelines.
- 1 Common Git workflows
- 2 Contributing Code
- 2.1 Contributing a new Feature
- 2.1.1 Get the latest changes
- 2.1.2 Create a local feature branch
- 2.1.3 Commit changes to local feature branch
- 2.1.4 Push changes to remote feature branch (Gerrit)
- 2.1.5 Review Changes on Gerrit (feature branch)
- 2.1.6 Apply commits from feature branch to develop
- 2.1.7 Rebase branch develop to origin/develop and Push to Gerrit
- 2.1.8 Review Changes On Gerrit (brach develop)
- 2.1.9 Delete Obsolete Feature Branches
- 2.2 Contributing a new Hotfix
- 2.1 Contributing a new Feature
- 3 GIT FAQ
Common Git workflows
This section presents some of the current workflows when using Git.
Push a single commit to Gerrit
We want to modify something on develop branch
- fetch the remote repository
- create a branch my_change at the same position as origin/develop
- activate the bug you want to work on in mylyn-task
- modify the files to fix the bug
- stage your changes
- commit your staged changes with an appropriate message (Bug number, bug title, description, url of the bug, change-id). If you are using mylyn the message will be generated. Use the Gerrit integration button to add and generate a change id.
- push to gerrit
- open your gerrit change (use the gerrit integration in Eclipse).
If you are sure, your change is good:
- review your change with someone and submit (+2)
- fetch to check that everything was fine.
Otherwise read #Push a second version of your change
Push a second version of your change
- do an additional modification
- stage and commit your changes. Choose the “Amend previous commit” option.
- Push to gerrit
- open your gerrit change: you should see the new version.
Push a modification on somebody else change
- find the change from somebody else that you should review
- click on “Fetch…” button
- checkout the change a new branch
- like in #Push a second version of your branch amend the commit and push to gerrit
Cherry-pick a commit into another branch
The idea is to cherry pick a commit from develop to a release/3.9.1 branch
- create a branch my_change_391 at the same position as origin/release/3.9.1
- cherry-pick the commit you want to back port on this branch.
Rebase your local branch on to of develop
Assuming you has started a branch like in #Push a single commit to Gerrit but you have not finished at the time, and other developers have pushed commits on develop in between. You need to rebase.
- checkout your branch
- select origin/develop an choose “rebase”. This means “rebase your current branch on…”
If you haven’t any conflicts:
- review you branch in the history view. The graph should show your branch on top of origin/develop
- solve the conflicts (see EGit User Guide, resolving a merge conflict)
Multiple commits on your feature branch
For work on bugs that require more time, you keep your working branch for a longer period of time
- Start by creating a local branch to work on #Push a single commit to Gerrit
- Create multiple commits to work on your bug
- In case of new commits on the origin/develop branch merge origin/develop on your current branch:
- fetch the origin remote
- On origin/develop click on "merge" (this means "merge origin/develop on the current branch")
- Create multiple commits to work on your bug
When your feature is ready:
- merge origin/develop to get the latest commits
- if you never backup your branch into an distant git repository create a second branch my_branch_backup. Do not checkout this new branch.
- reset your branch on origin/develop with the option Soft. This will leave your working directory and your index untouched. But your branch my_branch is now pointing at origin/develop. This means that when you create a commit, the parent will be the last commit of origin/develop but with all the file modifications contained in your feature branch.
- commit (do not forget the gerrit change id).
- there is no differences between my_branch and my_branch_backup but the commit history. my_branch has only one parent commit (that is in origin/develop). my_branch_backup contains all the intermediate commits from your feature branch.
- push this single commit (from your my_branch) to gerrit.
- TODO: push your feature branch in a remote repository for backup
- TODO: delete your branches
A common everyday workflow shown in the picture below. The steps that are always necessary are displayed in red.
When contributing features and patches you first need to think about on what release and branch it needs to be committed. An overview on branches is described here: Scout/Contribution_Guidelines#Git_Branching_Policy. A developer will usually one of the following:
- New feature: New features are only applied to the latest release. (If you think you have a "feature" that needs to be applied to a service release, let us call it hotfix.)
- Hotfix: An important bugfix that needs to be applied to the latest release and one or more older branches.
- Minor Bugfix: An minor bugfix that does not need to be applied to an older release.
The scenarios 1 and 2 are described here. 3 is done the same way as 1.
Contributing a new Feature
When you create a new feature you need to consider the following branches:
local branches: develop // local branch for HEAD <featureName>_<bugzillaid> //created by you for work in progress on your local machine remote branches: develop // your feature ultimately needs to be pushed here features/<committerId>/<featureName>_<bugzillaid> //created by you for work in progress
For every new feature we create a new branch. We do that because
- All changes of that feature are in the same place separate from the develop branch. We should have a better overview.
- We can share it with other developers before it is complete. We can make sure that only complete features are pushed to the develop branch.
- Working on multiple features in parallel is possible
- It is not much additional overhead
Get the latest changes
Before we start we make sure we have the latest changes:
- Checkout the local develop branch by double clicking it
- Fetch the latest changes: Right-click the git repository and choose Fetch from Upstream
- Pull: Right-click the git repository and choose Pull
Take a look at commit history (optional)
We can look at the commit history to see, if everything is as expected. Expand your local branches, right-click on develop and choose Show In -> History. We can see that our local 'develop branch (marked in green) refers to the same last commit as the remote develop branch shown as origin/develop in grey.
Create a local feature branch
We create and checkout a new local feature branch based on origin/develop with pull strategy None. We call the local feature branch description_bugzillaId, e.g. luna_target_bug412011.
Right-click on the commit where the origin/develop branch is pointing to and select Create Branch.... As Source ref or commit we select refs/remotes/origin/develop and call the local feature branch luna_target_bug412011. Select None as pull strategy and check Checkout new branch. Click on Finish. The feature branch should now be created locally.
The black checkbox icon on the left and the bold font in the History view indicate that the feature branch is currently active (checked out).
Commit changes to local feature branch
Now we do some changes and commit on the local feature branch.
In our example we made some initial changes for bug 412011 and are now about to commit a new file into the local branch. Switch to the view Git Staging. In the Unstaged Changes area all new and modified files are listed. We move the new eclipse-3.10I.target to the Staged Changes area by using drag-and-drop and enter a commit message.
Now we press the button Commit so that the target file will be committed into the local feature branch (Note: If we pressed the button Commit and Push, we would commit the target file into the local feature branch and also push those changes to the feature branch on the remote repository. However, we will do this step manually in this example).
If we look at the Commit History, we see that the local feature branch luna_target_bug412011 is 1 commit ahead of the remote feature branch origin/features/klee1/lunaTarget_bug412011.
Push changes to remote feature branch (Gerrit)
Now we push the recently created local feature branch to the remote repository on a remote feature branch. We do this to backup our work and allow other people to work on this feature. We also trigger a build on the sandbox hudson to verify the changes.
Right-click on the local feature branch luna_target_bug412011 and select Push to Gerrit.... The remote repository should already be the correct Gerrit Push URL. Press Next.
Now we choose the target ref name for the feature branch. The convention is as follow: The prefix refs/for indicates a special branch for Gerrit code review. The changes in the local feature branch will not directly be pushed into the feature branch of the remote repository. Instead, the changes are made available in Gerrit where code review can be done. In our example, the URL for code review is displayed Message Details box.
refs/heads/features/[committerID]/shortDescription_bug[ID], where [committerID] and [ID] should be replaced by the actual value. Press Finish and the feature branch should now be pushed onto the remote repository. There should be no error.
The feature branch is visible in the Remote Tracking directory.
Review Changes on Gerrit (feature branch)
After reviewing the code, the changes can be merged into the feature branch by clicking on the button Review and setting Code-Review +2 and IP-Clean to +1 and pressing Publish and Submit.
Switch back to EGit, right-click on the Scout RT Git repository and select Fetch from Upstream.
All branches will be fetched, i.e. our remote feature branch should be updated and be visible in the Commit History (Note: For the sake of simplicity we removed all irrelevant branches from the remote tracking folder). Currently, the local feature branch and the remote feature branch point to different commits, however they both contain the same changes. Therefore, we are going to rebase our local feature branch on top of the remote feature branch. Right-click on the remote feature branch and select Rebase on Top of.
The local feature branch and remote should now point to the same commit ID.
Apply commits from feature branch to develop
Before we apply our changes from the feature branch to the develop branch (currently the Scout Luna branch), we decide to make some further changes, commit them into the local feature branch and push them to Gerrit again (please repeat step 6). The new changes for our example are available here. As before, we review and apply these changes into the remote feature branch resulting the Commit History view to display something like this:
We now have two commits in our feature branch (remote and local) and both of them will be applied to to the origin/develop branch as 1 commit, i.e. in the Git context we squash our 2 commits from the feature branch into 1. To achieve this goal we reset our local feature branch luna_target_bug412011 to the remote origin/develop branch by right-clicking and select Reset -> Mixed (HEAD and Index).
Reset-Mixed means that the changes from the feature branch will be made available as Unstaged Changes. In the Git Staging perspective we move the changes to the Staged Changes area and commit them locally.
The Commit History looks like:
Rebase branch develop to origin/develop and Push to Gerrit
The local feature branch luna_target_bug412011 is now 1 commit ahead of the origin/develop branch, so we push this commit to Gerrit as follows: Select Push to Gerrit... and configure the dialog like this:
Review Changes On Gerrit (brach develop)
Hit Ctrl+Space in the Gerrit Branch field and choose develop branch, select refs/for/ in the drop-down field. After a successful code review at Gerrit, we apply this change into the remote develop branch.
After fetching the remote branches the Commit History should now display a new commit on the origin/develop branch.
Delete Obsolete Feature Branches
Not possible at the moment. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=408531.
Contributing a new Hotfix
When you create a new Hotfix you need to consider the following branches:
local branches: develop // local branch for HEAD release/x.y.z // local branch for service release (e.g. releases/3.9.1) <hotfixName>_<bugzillaid> //created by you for work in progress on your local machine remote branches: develop // your feature ultimately needs to be pushed here release/x.y.z // local branch for service release (e.g. releases/3.9.1) hotfix/<committerId>/<hotfixName>_<bugzillaid> //created by you for work in progress
When you create hotfixes you start as described with features, but instead of your remote feature branch your branch is now called hotfix. You do all the steps to push the change to develop and as a last step cherry-pick the change to the release branch.
Apply commit from develop to release branch(es)
Assume that the changes from the previous feature branch should also be applied to a release branch, e.g. release/3.9.1. Since we squashed our feature branch commits into the develop branch, we can just cherry pick that commit from the develop branch.
To do this checkout origin/release/3.9.1 to a local branch by right-clicking on the origin/release/3.9.1 and select Create Branch...
The local branch will be named release/3.9.1.
Press Finish and a new local branch should be visible and active.
We will now pick the commit from origin/develop that we would also like to have in our release branch 3.9.1. Right-click on the commit f3ea51c and select Cherry Pick.
The changes are automatically applied and committed to the local release branch.
As explained in step 7, we can push these changes to Gerrit. Right-click on the Scout RT Git repository and select Push to Gerrit... Enter release/3.9.1 in the Gerrit Branch field ans select refs/for/ as before.
Press Finish and follow the same procedure as described in step 7 for applying the changes in Gerrit to the remote release branch. Note: We abandon the change since this feature is only intended for Scout 3.10 and not for the release branch 3.9.1. However, the main message how to apply changes from the develop to a release branch should be clear.
How to Fetch a change from Gerrit
If somebody has pushed a change to Gerrit, and you like to modify something (push a new Patch set for the change), a good way is to fetch this change into a local branch. You can amend the commit and push it back to Gerrit.
With the Gerrit Mylyn Integration
- Open the Task representing the change (do not mix it with the task representing the bug).
- Expand the patch set you want to fetch
- At the bottom of the section, you will find a “Fetch Bottom”
- In the dialog “Fetch a change from Gerrit”, select “create and checkout a local branch” and provide a name that you can work with (for example: bug417010_bookmark_service_v2)
Without the Gerrit Mylyn Integration
- Go on the Gerrit Website, open the change
- Expand the patch set you want to fetch
- In the download row of the summary table, select “checkout” and copy the command line into the clipboard (use the small icon to do it).
- Back in Eclipse, in the Git Repository View, select the Git Repository.
- In the context menu select “Fetch from Gerrit…”
- The dialog “Fetch a change from Gerrit” pops up and it should parse the values from your clipboard.
- select “create and checkout a local branch” and provide a name that you can work with (for example: bug417010_bookmark_service_v2)