Sure, here's a simple simulation of how a trunk-based development might work with 5 students working on a simple Python application. We'll assume that each student is working on a different feature of the application.
-
Initial Setup: The instructor (or one of the students) creates a new repository on GitHub for the Python application. This repository contains the main branch (trunk).
-
Clone the Repository: Each student clones the repository to their local machine.
git clone https://github.com/instructor/python-app.git
-
Create a Short-Lived Feature Branch: Each student creates a new branch for their feature from the main branch.
git checkout -b feature-1 # Each student should replace "feature-1" with the name of their feature
-
Develop the Feature: Each student writes the code for their feature. They commit their changes regularly and push them to their feature branch on GitHub.
git add . git commit -m "Progress on feature" git push origin feature-1 # Replace "feature-1" with the name of the feature
-
Pull Request: Once a student has finished their feature, they create a pull request on GitHub. This is a request to merge their feature branch into the main branch.
-
Code Review: The instructor (or other students) review the code in the pull request. They may suggest changes or improvements.
-
Merge the Feature: Once the code has been reviewed and approved, it's merged into the main branch. The feature branch can then be deleted.
-
Update the Local Main Branch: After a feature has been merged into the main branch, all students should update their local main branch to get the latest changes.
git checkout main git pull origin main
-
Repeat: Steps 3-8 are repeated for each new feature.
This process ensures that all changes are integrated into the main branch frequently and that the main branch always contains a working version of the application. It also encourages collaboration and code review, as all changes are reviewed before they're merged into the main branch.
Releases:
Creating tags based on the date or commit number can be done in a similar way to creating version-based tags. The tag is just a reference to a specific commit, so it can be any string that makes sense for your project.
Here's how you can create a tag based on the date:
This will create a tag like
release-20220101
for January 1, 2022.And here's how you can create a tag based on the commit number (assuming you're using the short version of the commit hash):
This will create a tag like
release-1a2b3c4
.Then, you can push the tags to the remote repository in the same way as before:
Remember to replace
<tag_name>
with the actual tag you created.OR
In version control systems like Git, it's common to create a tag to mark a release. Tags function as references to specific points in your code history. They are often used to capture a point in history that is used for a marked version release (i.e., v1.0.0).
Here's how you can create a tag in Git:
git tag -a v1.0.0 -m "my version 1.0.0"
And then you can push the tag to the remote repository:
In this example,
v1.0.0
is the tag name and the-m
option lets you add a message to the tag. This can be useful for adding release notes or other important information about the release.