Create git-and-github.md

[rakaar]

Write path(s) which will be affected by this Pull Request. /events

Git and Github workshop is close to my heart. I feared using git in the beginning stages of development. I have found many beginners facing the same problem.

Hence, I feel that the important things related to Git and Github workshop should be documented. Many changes were made in the recent workshop based on past mistakes. So, it is important that future generations get to know things that have worked well and build ideas on top of them.

[rakaar]

Why can't I tag - kossiitkgp/advisors though there are in the teams - https://github.com/orgs/kossiitkgp/teams ? Hence I have tagged few people individually.

[OrkoHunter]

Probably the team is not added to the repository?

[rakaar]

Probably the team is not added to the repository?

@OrkoHunter Thanks. Added the team to the repo

[pranitbauva1997]

I have myself been confused about whether to teach beginners about rebase. One part of me thinks that git already has a very steep learning curve and it's not easy to get fluent in it right away, and thus overloading beginners with tons of new concepts can be overwhelming, while the other part of me thinks rebase becomes so frequent in day to day activities, a beginner might be afraid of it if he hasn't been taught about it.

Maybe we could re-think the way we do workshops and have the workshop in two parts with a gap of a week or two in between. The first part covers the bare minimum basics to get beginners excited to use the git tool and to make them think it's such a wonderful innovation while the second workshop gets into the nuts and bolts. We could also create some exercises to give them after part 1 and part 2 which could help them practice. If we do have two workshops, it's possible to cover a few more areas like the concept of remotes, stash, bisect (once I started frontend, bisect looks like a god-send), etc which are pretty much used widely and which make development hassle-free. If we have two workshops, then we can have each workshop for 2 hrs instead of 1 for 3 hrs.

On the other hand, I do think it's a reasonable expectation that once we have one workshop, we expect that they would do their own learning. The only issue with having one workshop is that after the workshop a significant majority feel exhausted and overwhelmed and they start fearing git. How do we make people think of it as their friend instead of something to be feared?

What are your thoughts about it?

[rakaar]

@pranitbauva1997 This is what I think. The main aim of our workshop is to teach the basics of Git and Github in a hands-on way. You said correctly that overloading the workshop with a bunch of concepts like rebase might be difficult for beginners. But if we succeed in teaching the basics properly, the audience can learn to rebase on their own from a short video like this.

I think that we should focus more on delivering the basics itself in a more intuitive way. That can be done with visualization tools like gitskool, more analogies, organizing the content well. If the basics are understood well, the audience will also have the confidence to try out more advanced concepts on their own.

Having 2 workshops for git is a great idea. But if it happens, I still insist that the first one should be 3 hours long with the same contents. The second workshop can be shorter(2 hours) and include topics like rebase, stash and bisect. Giving git exercises in the middle is a good idea. We can ask them to complete hacktoberfest in the meantime by sending PRs to metakgp repos or our repos.

Thanks for pointing it out - I have added the point regarding git advanced git workshop here - https://github.com/kossiitkgp/docs/blob/master/events/kwoc.md#miscellaneous

[rakaar]

@mukul-mehta @sahil-shubham @parth-paradkar @Shankusu993 @priyanshux Someone please squash and merge this PR. I cannot do as per below - https://github.com/kossiitkgp/docs/blob/master/.github/CONTRIBUTING.md

[sahil-shubham]

Merging this then.

[rakaar]

thanks man! @sahil-shubham