Git Kata Save
When you know the bases of git but sometimes you have problemes with it. This "code kata" could help you to deal with git problems
Git Kata, learn how to use git in team
When you know the bases of git but sometimes you have problemes with it. This "code kata" could help you to deal with git problems
| Duration | 2h30 |
|---|---|
| Supplies needed | - (optional) Story Cubes - video projector - internet |
| Max participant | Team of 4, max 12 people |
| Required skills | The objective of this workshop is to sharpen the use of git in teams in order to limit the everyday problems that can be encountered with Git (interdependence, conflicts,...) |
If you are a kata participant, follow these instructions
- One of the Dev team member should create an empty repository and share the url to the other members
- Make sure each participant have the possibility to commit and merge commit on this repository
- The repository should be empty
If you are the the workshop facilitator
SPOIL SPOIL Click here, don't spoil yourself if you are attendant SPOIL SPOIL
As a facilitator, your role will be to accompany the teams during the 2h30 workshop.
You need to:
- an internet connection
- a video projector
- (optional) Story cubes
Step 1: Explain the rules
READ As a team you will have to write a story. Each participant will have to write 2 sentences. You have 5 minutes to agree on the story to tell and share who should write which part. You should not talk about how you will organize yourself on the repository. (You can use Story cubes to generate the story) I must be able to find the author of each sentence. The story must be consistent and respect the concordance of time.
Step 2: Split the team
Make sure that the participants of the same team are positioned as far as possible in the room. They must not see what is displayed on their colleague's PC.
READ You must not communicate with others by any means. You can only communicate through the Github interface.
Step 3: Simmer for a maximum of 45 minutes
Let them do as they can for a maximum of 45 minutes. They should normally encounter several problems. If the team is doing well, introduce a new rule after 20 minutes.
READ You must write a back cover in another file
Take notes on what went wrong.
Step 4: Debrief with the team
You must look at the branches of the git tree. Talk about the problems encountered.
Let the team propose methods that would avoid worries. If the team has no ideas, suggest your ideas.
- Always start on a branch
- Use PR to let your friend read your content
- Use Merge, Rebase
Step 5: Starting from the beginning, this time it's the right one.
All in the title.
Feel free to share your feedback on the workshop in an issue.
- Any idea :bulb:
- Need help ?
Open Source Agenda Badge
