|
|
| (40 intermediate revisions by 9 users not shown) |
| Line 1: |
Line 1: |
| − | = Initial Setup =
| + | See [[Scout/Contribution/Setup]] and [[Scout/Contribution/Git_Workflows]]. |
| − | In order to work efficiently as a scout committer you need to setup your tools correctly. Here, we try to describe a setup that is simple and working. You only need to do this once.
| + | |
| − | | + | |
| − | We try to use a minimal set of tools, i.e. eclipse with [http://www.eclipse.org/egit/ egit] and [http://www.eclipse.org/mylyn/ mylyn] and a webbrowser. Many people also use [https://code.google.com/p/gitextensions/ gitextensions] or the command line, because more features are available. But it is possible contribute without these tools.
| + | |
| − | | + | |
| − | Please also read the [[Scout/Contribution_Guidelines | contribution guidelines]] before you start.
| + | |
| − | | + | |
| − | == Eclipse Installation ==
| + | |
| − | You need an eclipse IDE with [http://www.eclipse.org/egit/ egit] and preferrably [http://www.eclipse.org/mylyn/ mylyn]. You can use the [http://www.eclipse.org/downloads/packages/eclipse-scout-developers/keplerr scout EPP].
| + | |
| − | | + | |
| − | == Bugzilla ==
| + | |
| − | Make sure you have a Bugzilla account. [https://dev.eclipse.org/site_login/createaccount.php] and know how handle Bugzillas for Scout: (Read [http://wiki.eclipse.org/Scout/Contribution#Opening_new_Bugs] and [http://wiki.eclipse.org/Scout/Contribution#Bug_Life_Cycle])
| + | |
| − | | + | |
| − | == Contributor License Agreements ==
| + | |
| − | In order to contribute to Eclipse Scout, you need to sign the [[CLA|Contributor License Agreements (or CLA)]].
| + | |
| − | | + | |
| − | This is straight forward: connect to [https://projects.eclipse.org/user/login/sso projects.eclipse.org] and click on Contributor License Agreements. Read the document and answer the questions.
| + | |
| − | | + | |
| − | [[Image:CLA_01_home.png|400px]]
| + | |
| − | | + | |
| − | [[Image:CLA_02_questions.PNG|300px]]
| + | |
| − | | + | |
| − | [[Image:CLA 03 form.png|300px]]
| + | |
| − | | + | |
| − | == SSH Key==
| + | |
| − | An SSH Key is needed for authentication without username/password for pushing changes into the repository. For read-only access it is not necessary.
| + | |
| − | | + | |
| − | Here is how you create a new SSH Key in eclipse.
| + | |
| − | | + | |
| − | * Open Window / Preferences in eclipse
| + | |
| − | * Go to General / Network Connections / SSH2
| + | |
| − | * Open tab Key Management
| + | |
| − | * Generate DSA Key…
| + | |
| − | * Comment: email
| + | |
| − | * Enter Passphrase / Confirm Passphrase
| + | |
| − | * Save in C:\Users\username\.ssh. This is your private key. Make sure to always store it in a save place.
| + | |
| − | | + | |
| − | [[Image:GitContribution_createSSHKey.png|450px]]
| + | |
| − | | + | |
| − | In order to be able to push to git and gerrit, you need to upload your SSH key.
| + | |
| − | | + | |
| − | Gerrit is located here: https://git.eclipse.org/r/. Sign in with your email and password and add the key.
| + | |
| − | | + | |
| − | [[Image:GitContributionGerritSSHKey.png|300px]]
| + | |
| − | | + | |
| − | == Git settings ==
| + | |
| − | Before cloning update your git settings: Open Window/Preferences Team/Git/Configuration and add entries the necessary entries:
| + | |
| − | | + | |
| − | [[Image:gitSettings.png | 400px]]
| + | |
| − | | + | |
| − | * '''User Settings:''' Add '''user.name''' and '''user.email'''
| + | |
| − | * '''File Formatting:''' Add '''autocrlf=input'''
| + | |
| − | | + | |
| − | Contributed text files are stored in the repository in the following way:
| + | |
| − | * LF line endings
| + | |
| − | * UTF-8 formatted
| + | |
| − | * spaces instead of tabs
| + | |
| − | | + | |
| − | Formatting is done in eclipse with the .settings files linked to every project. Therefore, if everything is configured right, you do not need to worry about formatting.
| + | |
| − | | + | |
| − | Your git config file should contain the following entries:
| + | |
| − | | + | |
| − | [user]
| + | |
| − | name = Full User Name
| + | |
| − | email = ...@bsiag.com
| + | |
| − | [core]
| + | |
| − | autocrlf = input
| + | |
| − | | + | |
| − | == Get the Sources ==
| + | |
| − | There are [http://wiki.eclipse.org/EGit/User_Guide/Project_Set_File team project set] files available for easier initial cloning. Import the project set with File->Import->Team->Team Project Set.
| + | |
| − | Usually the Scout RT and Scout SDK are developed in different workspaces.
| + | |
| − | | + | |
| − | http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git/plain/org.eclipse.scout.rt.team-project-set/scoutRT.psf?h=develop
| + | |
| − | | + | |
| − | http://git.eclipse.org/c/scout/org.eclipse.scout.sdk.git/plain/org.eclipse.scout.sdk.team-project-set/scoutSDK.psf?h=develop
| + | |
| − | | + | |
| − | Alternatively you can also [http://wiki.eclipse.org/Scout/Contributions_Cloning_Scout_Manually#GIT_Repositories clone the sources manually].
| + | |
| − | | + | |
| − | === Gerrit Configuration ===
| + | |
| − | Although it is possible to push direclty to git, the common process is to push to Gerrit. We do this because
| + | |
| − | | + | |
| − | * A build is triggered automatically after a commit. You will be notified when the build is started and completed. That way we make sure that no commits that break the build or tests are submitted unnoticed.
| + | |
| − | * A commit can be reviewed and updated, if necessary.
| + | |
| − | | + | |
| − | Gerrit @Eclipse can be found here: https://git.eclipse.org/r/. The sandbox hudson for gerrit is located here: https://hudson.eclipse.org/sandbox/. It contains jobs for eclipse.scout.rt and eclipse.scout.sdk.
| + | |
| − | | + | |
| − | ==== SSH Key Generation ====
| + | |
| − | An SSH Key is needed for authentication without username/password for pushing changes into the repository. For read-only access it is not necessary.
| + | |
| − | | + | |
| − | Here is how you create a new SSH Key in eclipse.
| + | |
| − | | + | |
| − | * Open Window / Preferences in eclipse
| + | |
| − | * Go to General / Network Connections / SSH2
| + | |
| − | * Open tab Key Management
| + | |
| − | * Generate DSA Key…
| + | |
| − | * Comment: email
| + | |
| − | * Enter Passphrase / Confirm Passphrase
| + | |
| − | * Save in C:\Users\username\.ssh. This is your private key. Make sure to always store it in a save place.
| + | |
| − | | + | |
| − | [[Image:GitContribution_createSSHKey.png|450px]]
| + | |
| − | | + | |
| − | ==== Gerrit Settings ====
| + | |
| − | Gerrit is located here: https://git.eclipse.org/r/. Sign in with your email and password. In order to push your changes to git you need to upload an ssh key.
| + | |
| − | | + | |
| − | [[Image:GitContributionGerritSSHKey.png|300px]]
| + | |
| − | | + | |
| − | ==== Gerrit Push Configuration====
| + | |
| − | In the previous step we cloned our Scout RT repository read-only. To be able to push our feature branches and patches, we have to configure the Push URL to use Gerrit where write access is granted.
| + | |
| − | Therefore we change the push URL to point to Gerrit:
| + | |
| − | | + | |
| − | ssh://[username]@git.eclipse.org:29418/scout/[repository_name].git
| + | |
| − | | + | |
| − | [username] is your committer Id. E.g.
| + | |
| − | | + | |
| − | ssh://jgull@git.eclipse.org:29418/scout/org.eclipse.scout.rt.git
| + | |
| − | | + | |
| − | Expand the ''Remotes'' directory, right-click on ''origin'' and select ''Gerrit Configuration...''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep4.01.configure.push.url.png|400px]]
| + | |
| − | [[Image:GitContributionStep4.02.add.gerrit.png|400px]]
| + | |
| − |
| + | |
| − | Click on ''Finish''. Your Push URL should now look similar like
| + | |
| − | | + | |
| − | [[Image:GitContributionStep4.03.gerrit.added.png|400px]]
| + | |
| − | | + | |
| − | == Import Plugins Projects into Workspace ==
| + | |
| − | | + | |
| − | The sources are not stored in your workspace. You may create multiple workspaces for different purposes and use the sources stored in the local git repository. You most probably need one workspace for scout.rt and import all runtime plugins.
| + | |
| − | | + | |
| − | Double-click on the cloned repository ''org.eclipse.scout.rt'' and right-click on the ''Working Directory'' and select ''Import Projects...''. Import Existing Projects and select all plugins. Click on ''Finish'' to start the import process.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep2.01.import.into.workspace.png|400px]]
| + | |
| − | [[Image:GitContributionStep2.02.import.into.workspace.wizard.png|350px]]
| + | |
| − | [[Image:GitContributionStep2.03.select.plugins.png|350px]]
| + | |
| − | | + | |
| − | = 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 distant repository
| + | |
| − | * create a branch my_change at the same position as origin/develop
| + | |
| − | * if you use mylyn-task, activate the bug you want to work on
| + | |
| − | * modify the files to fix the bug
| + | |
| − | * stage your changes
| + | |
| − | * commit your stages 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 (in the browser or with the gerrit integration in Eclipse).
| + | |
| − | If you are sure, your change is good:
| + | |
| − | * review your change with someone and publish
| + | |
| − | * fetch to check that everything was fine.
| + | |
| − | Otherwise read [[#Push a second version of your branch]]
| + | |
| − | | + | |
| − | {{tip|Git Tip|
| + | |
| − | * When you use git, you have a complete clone of the repository. When you commit, this is done locally. This exaplains why there is a second operation “push” that correspond to “send my commits” to another distant repository.
| + | |
| − | * You files are in the working directory. When you modify a file, they are marked as “unstaged changes”. You can stage your modification. On commit only the staged changes will be considered.
| + | |
| − | }}
| + | |
| − | | + | |
| − | == Push a second version of your branch ==
| + | |
| − | * 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.
| + | |
| − | | + | |
| − | {{tip|Git Tip|
| + | |
| − | * When you amend a commit, you are rewriting the history. Meaning: you are deleting one commit that you replace with another one. You should not rewrite a change that is in a public branch.
| + | |
| − | ** you won’t be able to push it (unless you use –force)
| + | |
| − | ** if someone as already worked on top of your previous commit, it will be a mess. He is working on top a commit
| + | |
| − | * amending a commit is fine
| + | |
| − | ** when your commit only exist locally.
| + | |
| − | ** when you are pushing it to gerrit to modify an open change. Thanks to the “change-id” line, gerrit will recognize that you want to create a second version of the same change.
| + | |
| − | }}
| + | |
| − | | + | |
| − | == 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.
| + | |
| − | | + | |
| − | {{tip|Git Tip|
| + | |
| − | * like every git operations the cherry-picking is applied on your working directory. This means that you need to be on the branch where you want the cherry-pick to be applied.
| + | |
| − | }}
| + | |
| − | | + | |
| − | == 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
| + | |
| − | Else
| + | |
| − | * solve the conflicts (TODO: add a description – EGit workflow)
| + | |
| − | | + | |
| − | {{tip|Git Tip|
| + | |
| − | * rebase modifies your current branch (you’re working directory). The other branch is not modified. This is good way to remember the branch you need to checkout and the branch where you need to click rebase on.
| + | |
| − | * rebase also modify the commits. The same rules as for amend applies here.
| + | |
| − | }}
| + | |
| − | | + | |
| − | == 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
| + | |
| − | * TODO
| + | |
| − | | + | |
| − | {{tip|Git Tip|
| + | |
| − | * Do not let your feature branch diverge from the branch where you started and where you want to merge back at the end (develop in most of the cases). Regularly merge the branch into your feature branch.
| + | |
| − | * Backup your branch. If you only commit in your local repository, your work will be lost if you mess with you git repository, or if your computer is stolen or broken. You need to push your feature branch to a distant repository.
| + | |
| − | }}
| + | |
| − | | + | |
| − | = Contributing Code =
| + | |
| − | A common everyday workflow shown in the picture below. The steps that are always necessary are displayed in red.
| + | |
| − | | + | |
| − | [[Image:GitContributionCommonWorkflow.png]]
| + | |
| − | | + | |
| − | 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.
| + | |
| − | | + | |
| − | | + | |
| − | [[Image:GitContributionStep3.01.show.history.png|400px]]
| + | |
| − | [[Image:GitContributionStep3.02.history.timeline.png|600px]]
| + | |
| − | | + | |
| − | === 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.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep3.03.create.branch.png|550px]]
| + | |
| − | [[Image:GitContributionStep3.03.create.new.feature.branch.png|400px]]
| + | |
| − | | + | |
| − | 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).
| + | |
| − | | + | |
| − | [[Image:GitContributionStep3.03.feature.branch.created.png|400px]]
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | === 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=412011 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.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep6.01.commit.to.local.branch.png|500px]]
| + | |
| − | [[Image:GitContributionStep6.02.stage.and.enter.commit.message.png|500px]]
| + | |
| − | | + | |
| − | 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''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep6.03.commit.history.png|400px]]
| + | |
| − | | + | |
| − | === 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''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep5.01.push.feature.branch.to.remote.small.png|400px]]
| + | |
| − | [[Image:GitContributionStep5.02.select.remote.repository.png|300px]]
| + | |
| − | | + | |
| − | 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.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep5.03.choose.target.ref.name.png|300px]]
| + | |
| − | [[Image:GitContributionStep5.05.feature.branch.added.png|500px]]
| + | |
| − | | + | |
| − | The feature branch is visible in the ''Remote Tracking'' directory.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep6.06.gerrit.url.for.code.review.png|400px]]
| + | |
| − | | + | |
| − | === Review Changes on Gerrit (feature branch) ===
| + | |
| − | | + | |
| − | This [https://git.eclipse.org/r/14180 URL] can be opened in a browser. The [https://hudson.eclipse.org/sandbox/ Sandbox Hudson] will verify the supplied changes and set the ''verified'' flag if the build was successful.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep6.07.gerrit.in.browser.png|200px]]
| + | |
| − | | + | |
| − | 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''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep6.08.gerrit.publish.and.submit.png|200px]]
| + | |
| − | | + | |
| − | Switch back to EGit, right-click on the Scout RT Git repository and select ''Fetch from Upstream''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep6.09.fetch.from.upstream.png|200px]]
| + | |
| − | | + | |
| − | 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''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep6.10.rebase.png|200px]]
| + | |
| − | | + | |
| − | The local feature branch and remote should now point to the same commit ID.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep6.11.after.rebase.png|200px]]
| + | |
| − | | + | |
| − | === 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 [https://git.eclipse.org/r/14182 here]. As before, we review and apply these changes into the remote feature branch resulting the Commit History view to display something like this:
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.01.commit.history.png|200px]]
| + | |
| − | | + | |
| − | 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)''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.02.reset.mixed.png|200px]]
| + | |
| − | | + | |
| − | 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.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.03.squash.commit.png|200px]]
| + | |
| − | | + | |
| − | The Commit History looks like:
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.04.commit.history.after.commit.png|200px]]
| + | |
| − | | + | |
| − | === Rebase branch develop to origin/develop and Push to Gerrit===
| + | |
| − | | + | |
| − | TODO
| + | |
| − | | + | |
| − | 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:
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.05.push.to.gerrit.develop.branch.png|200px]]
| + | |
| − | | + | |
| − | === 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 [https://git.eclipse.org/r/14189/ 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.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep7.06.commit.history.after.merging.png|200px]]
| + | |
| − | | + | |
| − | === 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...''
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.01.checkout.release.branch.png|200px]]
| + | |
| − | | + | |
| − | The local branch will be named ''release/3.9.1''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.02.checkout.release.branch.dialog.png|200px]]
| + | |
| − | | + | |
| − | Press ''Finish'' and a new local branch should be visible and active.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.03.new.local.branch.png|200px]]
| + | |
| − | | + | |
| − | 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''.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.04.cherrypick.png|200px]]
| + | |
| − | | + | |
| − | The changes are automatically applied and committed to the local release branch.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.05.commit.history.after.cherrypick.png|200px]]
| + | |
| − | | + | |
| − | 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.
| + | |
| − | | + | |
| − | [[Image:GitContributionStep8.06.push.to.gerrit.release.branch.png|200px]]
| + | |
| − | | + | |
| − | 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 [https://git.eclipse.org/r/14193 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.
| + | |
| − | | + | |
| − | = GIT FAQ =
| + | |
| − | == How do I keep my feature branch up to date? ==
| + | |
