Git Workflow, by Brian McCutchon

This git workflow for Eclipse is based on the git Centralized Workflow as described here:!workflow-centralized
Before you start, you should read the section entitled
Minimizing Conflicts.”


Minimizing Conflicts

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:

  1. Edit the file(s).
  2. Whenever you make a significant change,
    commit it.
  3. When you are ready to share your changes with the team,
    push your changes upstream.

To add a new file or files:

  1. Create the file(s).
  2. 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.
  3. When you are ready to share your changes with the team, push your changes upstream.

To delete a file:

  1. Delete the file from Eclipse.
  2. 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.
  3. Commit the change.

To push changes upstream:

  1. 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.”
  2. 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:

  1. If you haven’t already done so, configure pull to rebase by default.
  2. 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.”
  3. If conflicts occur, you may have to resolve them manually.

To configure pull to rebase by default (modified from an answer by robinst on Stack Overflow):

  1. Open the Git Repositories view.
  2. Locate [Your Project Name Here] > Branches > Local > master.
  3. Right click on it and select “Configure Branch…” from the context menu.
  4. In the dialog that appears, check the “Rebase” box and press “OK.”

To commit a change:

  1. Open the Git Staging view.
  2. 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.

    IMPORTANT: Make sure that you include all files on which your main commit depends. For example, if you add a method to class A which uses a new method that you added to class B, you must include B as well as A. Otherwise, other people may end up with a copy of class A that will contain errors. This also applies for images: if C.jpg is referenced in class A, you must also commit C.jpg. As a general rule, it is best to commit everything that you have changed.
  3. Write a meaningful commit message (see below).
  4. 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
blog post

  • 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.

References/Further Reading: