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 💡
• Need help ?