This git workflow for Eclipse is based on the git Centralized Workflow as described here:
Before you start, you should read the section entitled
- Minimizing Conflicts
- Editing existing files
- Adding new files
- Deleting files
- Pushing changes
- Pulling changes/rebasing
- Committing changes
- References/further reading
If two people begin working on the same files, conflicts may occur. Rather than fix large file conflicts, it is best to keep your local repository synchronized with the central repository so that, if they do occur, these conflicts will be smaller and more easily resolved. To do this, you should push and pull changes often when connected to the central repository and making changes.
To edit an existing file or files:
- Edit the file(s).
Whenever you make a significant change,
When you are ready to share your changes with the team,
push your changes upstream.
To add a new file or files:
- Create the file(s).
- You should commit the file when it reaches a state at which it serves its most basic function. For graphics, this could be anything from a placeholder image to a fully developed graphic. If you are creating a placeholder image, it is best to give it the name it will have when it is complete, i.e. “logo.png”. Then whoever replaces it with the final copy can simply overwrite “logo.png” without the need to modify the code where “logo.png” is referenced.
- When you are ready to share your changes with the team, push your changes upstream.
To delete a file:
- Delete the file from Eclipse.
- Open/go to the Git Staging view. The file you deleted should listed in the “Staged Changes” area with a small gray “X” in the bottom-right corner of its icon.
- Commit the change.
To push changes upstream:
- Press the “Push changes to upstream” button. It depicts a straight red arrow pointing to a yellow cylinder. This can also be done by right-clicking on the project and selecting “Team > Push to upstream.”
- A loading bar should pop up, followed by another dialog box. If you see the message “master: master [rejected – non-fast-forward]” in the center pane, it’s time to rebase. Otherwise, you’re done.
To pull changes/rebase:
- If you haven’t already done so, configure pull to rebase by default.
- Pull changes. This can be done by clicking the “Pull changes from upstream into current branch” button (red arrow pointing away from yellow cylinder and downward in the toolbar) or by right-clicking on the project and selecting “Team > Pull.”
- If conflicts occur, you may have to resolve them manually.
- Open the Git Repositories view.
- Locate [Your Project Name Here] > Branches > Local > master.
- Right click on it and select “Configure Branch…” from the context menu.
- In the dialog that appears, check the “Rebase” box and press “OK.”
To commit a change:
- Open the Git Staging view.
- In the Unstaged Changes section, you should see a list of the files that you have not committed. Move all files on which your commit depends to the Staged Changes section.
- Write a meaningful commit message (see below).
- When you are done, press “Commit.” If you are connected to the repository and wish to share your changes, you may press “Commit and Push.”
Here are some guidelines for writing good commit messages (taken from this
- The first line of the commit message should be a short description (50 characters is the soft limit), and should skip the full stop
- The body should provide a meaningful commit message, which:
- uses the imperative, present tense: “change” not “changed” or “changes”.
- includes motivation for the change, and contrasts its implementation with previous behaviour.
I will add that the body is optional, but should be generally included in the case of code changes. Here is an example (contrived) commit message:
Add collision Create the class CollisionChecker, which stores information about the physical environment and can be used to determine whether two objects have collided. Previously, the game had no method for determining collision, allowing players to pass through walls, etc.