Github-for-beginners: a practice repository where the pull request is the exercise

The repository is the classroom, not a set of slides

Github-for-beginners is a practice repository for learning essential GitHub workflows, and the design decision is that the student makes a real contribution rather than completing a tutorial.

The list of what you learn is the list of what you actually do. You fork a repository, you clone it to your local machine, you create and switch between branches, you make changes to files, you stage and commit them, you push to GitHub, you create pull requests, you work with issues, and you use the basic Git commands along the way.

What makes it a workshop rather than a reading exercise is the shape of the contribution. The file you edit is student-introductions.md, you add an introduction following the template, and your exercise is a branch, a commit and a pull request against the upstream project. The pull request is the deliverable, and the repository owner reviews it. That is a meaningful difference from a local practice repo, because the feedback loop is the real one: a maintainer reads your diff, a conversation happens in the review, and the merge is somebody else's decision.

The repository also carries the supporting material for that format. There is a docs/ directory with a prerequisites PDF, a guides/ directory, a LEARN.md file, a practice-file.md, a standalone git-commands-reference.md, and a support md files directory with the troubleshooting guides the instructions refer to. Instruction videos are provided in English and Sinhala, which is a reasonable signal about who the workshop is aimed at.

Prerequisites are Git, an editor, and a folder to work in

Before any exercise, the documentation asks you to have Git and Visual Studio Code installed, and a detailed prerequisites guide is available as a PDF in the docs folder.

For Git on Windows the steps are to download it from git-scm.com, run the installer, use the default settings, which the documentation recommends for beginners, and verify the installation by opening Command Prompt or PowerShell and running:

git --version

For macOS the recommended route is Homebrew:

brew install git

with the option of downloading from git-scm.com instead, and the same verification step in Terminal.

Visual Studio Code is downloaded from code.visualstudio.com, and one extra step is called out: install the VS Code command line tool, which is what lets you open a project from the terminal.

There is also a piece of workspace advice that is more about habit than tooling. Create a dedicated folder on your desktop called workshop for this project, and open your terminal or command prompt from that location before you clone. For Windows users there is a separate support file for the Command Prompt setup, because getting the current directory right on Windows is a genuinely common place for a beginner to lose twenty minutes.

The design here is deliberate: the environment is prepared once so that the exercises can be about Git, and everything that is not Git is pushed into a support document.

Five exercises, one file, and a branch named after you

The exercise sequence is explicit, and it is worth following in order because each step depends on the last.

Step one is to click the Fork button, which creates a copy of the repository in your own GitHub account, with a detailed guide in the support files. Step two is to clone your fork:

# Replace 'your-username' with your actual GitHub username
git clone https://github.com/your-username/Github-for-beginners.git

# Navigate to the project directory
cd Github-for-beginners

Step three is the branch, and the naming convention is part of the exercise. The command is git checkout -b feature/your-name-introduction, or the two step form of creating the branch and then checking it out.

Step four is to open student-introductions.md, add your introduction following the template and save the file. Step five is to stage and commit, starting with git status to see what changed, then git add student-introductions.md for the specific file or git add . for everything, and then a commit with a descriptive message, git commit -m "Add introduction for [Your Name]".

Step six pushes the branch to your fork with git push origin feature/your-name-introduction, and step seven is the pull request, from your fork on GitHub, where you click Compare & pull request, add a title and a description, and create it.

The work itself is deliberately tiny. One file, one paragraph, one branch. The complexity is in the workflow, not in the content, which is exactly the right shape for a first exercise.

The git identity mistake that stops every beginner

There is one failure mode the documentation calls out with a warning, and it deserves the same treatment because it is the one that reliably stops a session dead.

If Git does not recognise your name or email during commits, you cannot commit at all. The warning explains the consequence plainly: it can prevent you from committing changes. The fix is in a support file, Git-Configuration-Troubleshooting.md.

The reason this is worth reading in advance is that the error message is not self explanatory for a newcomer. The commit is rejected at the moment you think you have finished the work, the message talks about identity rather than about the file you just edited, and the natural reaction is to think something is wrong with the repository. It is not. Git needs a name and an email to stamp on a commit, and on a fresh machine it does not have one.

Two smaller pieces of the same advice are scattered through the documentation and are worth collecting. The first is to use a dedicated workshop folder and to open the terminal from it, because a clone that lands somewhere unexpected causes the same confusion in a different form. The second is to check what you are about to commit with git status before staging, which is a habit the exercises teach in passing and which pays for itself far beyond this repository.

What completion means and how submissions are reviewed

The submission guidelines define what finishing the workshop actually involves, and it is more than opening a pull request.

You move to the main repository, the original one, by switching your remote to the upstream or main repository if needed. Then you create an issue on that branch using the Submission template, and the issue has to include four things: your GitHub username, links to your pull requests, a screenshot of your contribution, and a brief reflection on what you learned.

The checklist is the grading criteria, and it is worth reading literally. You must have successfully forked the repository, cloned it to your local machine, created at least two different branches, made commits with good commit messages, pushed branches to GitHub, created at least one pull request, created at least one issue on the main repository, and added your introduction to the student introductions file.

The issue templates available in the repository are Bug Report, Feature Request, Question and Submission, and the issue best practices section asks for descriptive titles, detailed descriptions, relevant labels, and references to related issues or pull requests using the number syntax.

Two of the requirements are worth a moment. The screenshot of your contribution is there because a newcomer who has never seen a diff may not know what one looks like from the GitHub interface, and the reflection is there because the person reviewing your issue is trying to judge what you understood, not what you copied.

The command reference is older than some of your habits

The repository includes a git-commands-reference.md file and a Common Git Commands Reference section in the README, and it is worth reading as documentation of the workflow rather than as a cheat sheet to paste.

The commands it teaches are the classic set. git status to check the repository status, git log --oneline to view the commit history, git branch to check the current branch, git checkout to switch branches, git checkout -b to create and switch to a new branch, and git branch -d to delete a branch. For changes there is git add for a specific file, git add . for everything, and git commit with a message.

The style is the older one. Branch creation with git checkout -b has been the subject of a long argument in the Git community, and the newer git switch and git restore commands were written partly to make the intent clearer when you are moving between branches or restoring a file. Nothing here is wrong, and for a first exercise the consistency of a single style is arguably a virtue. But a person who later reads a modern tutorial will meet different verbs for the same operations, and the mapping is worth knowing.

The rest of the tree is the workshop's supporting material: the .github/ directory holds the issue templates, the guides/ and docs/ directories hold the written material, the images/ directory holds the screenshots used in the README, and student-opportunities/ is a directory for the wider set of opportunities the project points learners towards.

Where a workshop repository stops being useful

Two limits are structural, and they are the same limits every practice repository has.

The first is that you cannot depend on it. This is not a library, there is nothing to import, and the content is a single markdown file that you are meant to change. Once you have done the exercises twice, the repository has given you what it can. The workflows it teaches, forking, branching, committing, pushing and opening a pull request, are the durable part, and they are better learned on a repository you actually care about than on a workshop copy.

The second is that it teaches one route. The exercise sequence is a fixed path: one repository, one file, one branch, one pull request, one issue. Real work on a team repository is different, because you work on someone else's branch, you rebase onto a moving main, you resolve a conflict, you take review feedback and amend a commit. None of that is in the exercises, and a learner who stops here will meet all of it on their first day of work.

The alternative is the general one: a tutorial that gives you the same commands without a place to practise them, or a live repository of your own with a maintainer who will review your pull request. The difference in approach is that this repository supplies a fixed sequence with videos, support documents, issue templates and a person checking your submission, while a tutorial supplies explanations and no feedback. For a first pass, the feedback is the more valuable half.

Editorial conclusion

Adopt Github-for-beginners if you are learning GitHub and want a real fork, a real branch and a real pull request rather than a simulated one, and you are comfortable working in a fork and a pull request workflow. Do not adopt it as a dependency or a reference implementation, since it is a workshop with a single editable markdown file, and do not follow its older command style into a modern repository without checking the equivalents. Verify first that the upstream repository still accepts pull requests, that the submission issue template is still active, and that the branch and commit naming conventions in the checklist are what a reviewer there expects.

Frequently asked questions

Official sources

1. Issues
2. nisalgunawardhana/Github-for-beginners on GitHub
3. Project website
4. README