Platform-releng/Git Workflows
We'd like to capture some common CVS workflows used by the Eclipse Project and spell out the git/EGit equivalent.
Refer to the EGit/User Guide for more detailed instructions and pictures.
Contents
Clone a repo
The first step is to clone the one or more repos you need to work on. You want to clone the repo to a location outside your workspace. Then use the EGit Import Projects option to import the projects.
Refer to the EGit/User Guide for more detailed instructions and pictures.
- Switch to the Git Repository Exploring Perspective
- Use Clone a Git repository
- you can paste in your connection URL and it should do the right thing. Some URLs (not all of them contain content right now in the testing phase):
- ssh://userid@git.eclipse.org/gitroot/equinox/rt.equinox.bundles.git
- ssh://userid@git.eclipse.org/gitroot/equinox/rt.equinox.framework.git
- ssh://userid@git.eclipse.org/gitroot/equinox/rt.equinox.incubator.git
- ssh://userid@git.eclipse.org/gitroot/equinox/rt.equinox.p2.git
- ssh://userid@git.eclipse.org/gitroot/equinox/rt.equinox.security.git
- ssh://userid@git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git
- ssh://userid@git.eclipse.org/gitroot/jdt/eclipse.jdt.debug.git
- ssh://userid@git.eclipse.org/gitroot/jdt/eclipse.jdt.git
- ssh://userid@git.eclipse.org/gitroot/jdt/eclipse.jdt.ui.git
- ssh://userid@git.eclipse.org/gitroot/pde/eclipse.pde.build.git
- ssh://userid@git.eclipse.org/gitroot/pde/eclipse.pde.git
- ssh://userid@git.eclipse.org/gitroot/pde/eclipse.pde.incubator.git
- ssh://userid@git.eclipse.org/gitroot/pde/eclipse.pde.ui.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.debug.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.releng.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.resources.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.runtime.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.swt.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.team.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.text.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.ua.git
- ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git
- Next
- Select all branches to clone
- Next
- Confirm the location that it will clone the repository into.
- an initial branch of master and a remote name of origin are standard.
- Finish - Now just sit back while git copies the entire repo to your harddrive :-)
We need to get the projects from the repo into our workspace:
- right click on your newly cloned repo and select Import Projects
- you want Import existing projects from the Working Directory
- Next
- Select the projects that you want to import from the repository
- Finish
Now you can start working.
Start working in HEAD
To start working in HEAD you must clone your repository and checkout a working copy. By default, cloning the repo checks out the master branch, which is the same as HEAD in CVS.
See #Clone a repo.
Refer to the EGit/User Guide for more detailed instructions and pictures.
The constant HEAD is used in GIT as well, but has a completely different meaning. In GIT HEAD means the pointer to the latest commit in your currently checked-out branch (more or less).
Start working in a new branch
For example, create the R3_7_maintenance branch for your repo. This example is for the case that your branch doesn't already exist as refs/remotes/origin/R3_7_maintenance.
Refer to the EGit/User Guide for more detailed instructions and pictures.
- right click on one of your projects and choose Team>Switch To>New Branch
- you need to pick a source ref.
- HEAD == current checked out commit
- refs/heads/master means your master branch.
- refs/remotes/origin/R3_7_maintenance - the existing remote branch. If you pick this one and name your local branch the same, EGit will automatically create a tracked branch.
- refs/tags/R3_7 is the tags to branch from
- name the branch R3_7_maintenance
- leave "Check out the new branch" selected.
This will create a new branch for you to work on. Once you've made your initial commits, you need #Commit changes to the main repo. Pushing up to the repo will push any new branches you've created as well.
Create a patch
We have 2 options for accepting contributions from the community. See Development_Resources/Handling_Git_Contributions (prefered) and Git#IP_process_implications_of_DVCS. Refer to the EGit/User Guide for more detailed instructions and pictures.
To create a patch:
- You need to show the commits in the history view.
- Either right-click on a file you just committed and Show in history
- or right-click on the project and Show In>History, then find the commit you want
- right click on the commit in the History view, and select Create Patch
- use Next if you'd like the patch in the standard git mbox format
Apply a patch
A normal workspace patch will apply in the same fashion it does for CVS. Simply copy the file to the clipboard and paste it into the Package Explorer or use Team>Apply Patch.
Refer to the EGit/User Guide for more detailed instructions and pictures.
Patches created with git/EGit have a different pattern. They are diff statements that look like:
diff --git a/bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/HandledContributionItem.java b/bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/HandledContributionItem.java index 99d339f..37bcf68 100644 --- a/bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/HandledContributionItem.java +++ b/bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/HandledContributionItem.java
To apply a patch like this, you should:
- copy and paste the patch into the Package Explorer
- Select Apply patch to the workspace root
- Next
- under Patch Options set Ignore leading path name segments to 2
- now you can examine the patch and apply is normally.
Tag the mapfile for a build
We're still deciding on a best practice on tagging the repos and updating the map files for an I build.
One option under discussion is to allow the I build to tag the repos and update the map files automatically based on master. In the normal case, the build will run with master. If we need a fix, a map file can be reverted and a new I build with "no repo tagging" can be started.
When we have a bug for the discussion I'll update this item with the number.
Commit changes to the main repo
Committing a change to the main repo is a 2-step process in git. In git, a commit creates a commit with the changed files in your local clone repository. A push will put that commit in our main repo. Committing and pushing are distinct operations in git.
Refer to the EGit/User Guide for more detailed instructions and pictures.
To get your changes to the main repo in EGit:
- Do a pull or a fetch and a merge into your working branch
- right-click on your project and use Team>Commit
- Your commit message should include the bug number you are using for your fix/work.
- check the files that should be included in the commit in the Files section
- Commit
Then you need to push your changes to make sure they've visible to everyone else
- right-click on your project and use Team>Push to Upstream
- it should provide a status dialog with the refs that were updated, or a failure if the main repo has commits that you haven't either merged or rebased on.
- if there's a failure, you need to #Update to pull in the latest changes to HEAD or the relevant branch.
Common commit message:
Bug 349177 - [releng] stitch ui.workbench fork back into main Updating some code to reflect the real change
Update to pull in the latest changes to HEAD
Refer to the EGit/User Guide for more detailed instructions and pictures.
Merge conflicting changes
Refer to the EGit/User Guide for more detailed instructions and pictures.