Git на хакатоне: как объединять код и не потерять демо

Git helps teams keep a shared project history and combine everyone's work at a hackathon. For small groups, a simple structure suffices: establish a main branch, make small changes, and have someone review the results before merging. Don't introduce complex branching mid-competition. Git tracks file versions. Platforms like GitHub add collaboration, discussions, and access control.

Teams can choose any permitted tool, but they must know the location of the shared repository and what version is ready for demo. Verify access rights before the first task. Create a repository in the agreed upon account or organization, add participants with appropriate permissions, and ensure invitations are accepted. Set visibility according to event conditions and material nature.

Closed repositories may require a separate jury access. Open repositories should not contain personal data, drafts, or secret keys. If the organizer demands publication, prepare the project for it before the final hour. Add a short startup instruction and a configuration file with local settings, temporary files, and installed dependencies.

A sample configuration should describe necessary parameters without real secrets. Don't rely on accidentally inserted keys disappearing after removing a line in a new change. Agree on the working main branch. Keep the main branch with a version that can be run according to instructions. Leave experimental branches separate. The main branch should contain a version that can be run according to the instructions.

Work on separate, verifiable changes. When merging, explain the behavior. GitHub's documentation on pull requests explains the proposal, discussion, and merging of changes. At a hackathon, the description can be brief: what was changed, how to check it, and any remaining limitations. Include a screenshot for the screen and an example input/output for processing data.

The verifier checks the modified scenario, ensuring no shared boundaries are affected. The author knows their task better, but another participant might notice an unavailable environment variable or error hidden by local data. Don't require a long formal review for each push. Focus on changes affecting startup, data format, access, and demonstration.

Share work on files and interfaces. If two people edit the same large component simultaneously, conflicts are likely. Agree on boundaries: one person works on loading, another on the result screen. Agree on the data schema before parallel work. Notify about changes to shared dependencies or project structure. Notify about tool updates that might affect everyone's startup.

During short events, have a specific reason for changing shared code, not just a desire to standardize the entire repository. When a conflict arises, don't automatically choose "our" or "their" version. Read both edits and determine the behavior each adds. If unclear, ask the author. Deleting someone's error handling accidentally is easier than noticing its loss during a quick review.

Verify the project after merging parts. Run the main user path and run any available automated tests. Don't add a complex testing system just for a report if the team can't use it. Designate someone to monitor the overall build. This doesn't mean they have the only right to merge code. Their task is to notice when the team loses track of the current state and stop new changes until the workflow is restored.

Save a version to protect the work. Record the dataset used and known limitations. If you fix behavior after recording, check if the video reflects the updated project. Don't rewrite the overall history without team agreement. Avoid force-pushing changes as it can disrupt others' work. If secret data is accidentally added, limit it to just clearing files: revoke compromised access according to the respective service's rules and inform the responsible participant.

A demo failure example: a developer added a new parameter but didn't update the instructions. It works on their computer but fails for the presenter. Checking on a second device detects this before the final. That's why task completion includes reproducible startup, and project submission includes verifying access to the correct version.

Before submitting the repository, find the requirements for the selected event via the Stavleak directory. Check the material composition and the deadline by which the jury needs access.