Spartan Git How To

#Working Tools & Installation Details: ###Git Staging (Recommended): In Eclipse, ‘Help’ -> Install New Software -> --All Available Sites-- -> Search for Git -> Install available updates. Add Git Staging tab to active window views: Click Window->Show View-> Other and select “Git Staging” under the “Git” directory.

###GitHub Gui & Shell: https://desktop.github.com/

#Technical How-To – Pull, Commit & Push: ###From Inside Eclipse (Recommended): Pull: Go to project explorer, right click on the project->Team->Pull. Commit and Push: Git Staging is a window view and an easy graphical interface for committing and pushing. When you make an update to some file it appears in the ‘Untagged Changes‘ window. You can drag and drop files from the ‘Unstaged Changes‘ to the ‘Staged Changes‘ and back, without being afraid of crashing the project. After dropping some updated files into ‘Staged Changes‘, you should describe shortly what have you changed in those files. Finally you can click ‘Commit‘ to commit without pushing or ‘Commit and Push‘ to save the changes into the remote repository (the real project on github). ####Tip: Git Staging tab must be one of the active window views during the update otherwise it may not recognize the changes. In this case you should use command line instructions add, commit and push.

###Git Shell: Pull changes from Github: git pull. Commit changes: ‘git add ’ to add files to the commit. ‘git commit – m ""‘ to commit the added files. Push changes: ‘git push’.

#Technical How-To – Spartanization and Cleanup: ###Spartanization: To spartanize, go to ‘Refactor’ menu, -> ‘Spartanize’ under in Eclipse, and choose ‘Spartanize active window’. At times, the spartanization will suggest without active prompting from you. One wring will be done at a time. ###Cleanup: Go to Source -> Clean Up to invoke Eclipse’s cleanup option.

#Developer’s How-To & Best Practices:

1. Always pull before you start your work.
2. Refresh the project (Ctrl-F5).
3. Code writing goes here.
4. Make sure that all tests with @test annotation pass before you commit them. Failing tests can be committed with @ignore flag.
5. Spartanize your code before committing. Make sure you have exhausted all (reasonable) spartanization suggestions.
6. Use Cleanup.
7. Use Organize Imports and Sort Members (both under Source menu)
8. Git pull once more.
9. Commit often. Remember that committing only updates your local repository.
10. Commit Messages (that’s the part in which you update your local repository): a. Try to be short and clear, remember the “half screen” rule - a lazy reader sees only half of the screen, or in other words first 5 words. If you can’t describe your changes in 5 words, at least make them introduce the main idea and you will see how the description is already shorter. b. Cherry Picking: Committing must be divided into logical groups. Each commit must have one purpose, which must be described by the commit message. Avoid committing a lot of file at once and writing long stories in the commit message. For example adding new wring with tests includes at least 3-4 files to be changed - commit them together. The rationale behind is maintaining accurate recovery points in case your commits turn out to be destructive.
11. Don’t forget to git push (that’s the part in which you update the remote repository and potentially ruin the project. So, be careful).

#Pull, Commit and Push Related Problems and How to Solve Them: ###Pulling: Sometimes you will work on the same file with your partner or even accidentally with someone else. In this case when you will pull again before pushing you will get Collisions. Those will edit the relevant files in the next way:

Equivalent code

">>>>>>" HEAD

Your code

"======="

Other’s code

"<<<<<<"

Equivalent code

You should merge those files manually and then commit and push.