Institute of Computer Science
  1. Courses
  2. 2025/26 fall
  3. Mobile Application Development (LTAT.06.021)
ET
Log in

Mobile Application Development 2025/26 fall

  • Introduction
  • Lectures
  • Tutorials
  • Project Requirements
  • Project Ideas
  • Readings
  • Git Etiquette
  • Course Rules & Regulations
  • Evaluation

Git Etiquette for Mobile App Development

This document outlines the strict Git protocol for this course. Following these rules is not optional; it is a fundamental part of your project grade and essential for effective teamwork.


General Principles: What to Commit

Your Git repository is for source code and essential project files that cannot be automatically created by your build tools.

  • Only Commit Non-Generatable Files:
    • Allowed:
      • Source code (Kotlin, XML, etc.)
      • Configuration files like `build.gradle` and `.gitignore`
      • Non-generatable assets like original images (or photos of sketches or mockups, potentially also animated gifs), PDFs (not if you can easily create them as mark-up), or other media files - due to size issues, link to videos.
    • Forbidden:
      • No binaries. This includes compiled `jar` files, `apk` files, and any other compiled output. This also includes Word documents or Excel tables (or their LibreOffice equivalent). Try modeling tables in markup or in exceptions if it is really very complex and big, save it as a PNG as a screenshot from a Google spreadsheet that you link (ask your instructor or TA for that exception).
      • No Android Studio settings. Do not commit your `.idea/` folder or other IDE-specific configuration files.
      • No Gradle outputs. Do not commit the `build/` directory or any of its contents.
  • Use a Good .gitignore starter file: A proper `.gitignore` file is your first line of defense. It prevents accidental commits of binary files, settings, and other noise. Attention: this starter file still needs to be edited.

Workflow: How to Work

  • Commit Often: Make small, frequent commits with clear, descriptive messages.
  • Everybody Works on Git: Every team member must actively contribute to the Git repository. The project log should show that all four members are pushing code regularly.
  • Reduce Branching, Do More Merges: With only four people per team, a complex branching strategy is unnecessary.
    • Work on a common branch (e.g., `main` or a feature branch) and merge frequently.
    • Before you start, always `pull` the latest changes.
    • When you complete a task, `push` your changes immediately.

These rules are designed to prevent common project issues and teach you professional-grade practices. There will be no exceptions.


Learn More About Git

  • Git Book: A free and comprehensive guide to Git.
  • Learn Git Branching: An interactive tool to learn Git commands visually.
  • Atlassian Git Tutorials: A series of tutorials covering basic and advanced topics.
  • Institute of Computer Science
  • Faculty of Science and Technology
  • University of Tartu
In case of technical problems or questions write to:

Contact the course organizers with the organizational and course content questions.
The proprietary copyrights of educational materials belong to the University of Tartu. The use of educational materials is permitted for the purposes and under the conditions provided for in the copyright law for the free use of a work. When using educational materials, the user is obligated to give credit to the author of the educational materials.
The use of educational materials for other purposes is allowed only with the prior written consent of the University of Tartu.
Terms of use for the Courses environment