The portfolio is on GitHub and changes reach main through pull requests. Two questions remain. How do you keep track of what to do next, without a sticky note on your monitor? And how do you contribute to a project you don’t own, where you can’t even push a branch? GitHub answers the first with issues and Projects, and the second with forks.
An issue is a tracked piece of work: a bug, a feature idea, a question. Each gets a number shared with pull requests (#12), a discussion thread, and metadata:
bug, enhancement, documentation, good first issue.For your portfolio, write the to-do list as issues: “Projects page: filter by tag (#12)”, “Footer overlaps content on mobile (#13)”. Then each pull request names its issue with Closes #12, merging closes it, and six months later anyone can follow the trail from a line of code to the commit, the pull request, the discussion and the original reason.
A good bug report has steps to reproduce, what you expected, what happened, and the browser or version. Repositories can add issue templates in .github/ISSUE_TEMPLATE/ so reporters fill those sections in automatically.
A GitHub Project is a planning view over issues and pull requests, possibly from several repositories. It starts as a spreadsheet-like table; you add custom fields such as Status, Priority, Size or Iteration, and switch between table, board (columns by Status, the familiar kanban) and roadmap (items on a timeline) layouts. Built-in workflows can move items automatically, for example to Done when an issue closes or a pull request merges.
\nFor a solo portfolio, a board with Todo, In progress and Done is plenty. On a team, the Project is where planning conversations happen and the issues hold the detail.
\nSay you’ve found a typo in the docs of an open-source theme library, open-themes/vite-themes. You can clone it, but you can’t push to it: you’re not a collaborator, and git push fails with a permission error. That’s what forks solve.
A fork is your own copy of the repository on GitHub, under your account: maya-okafor/vite-themes. You can push anything to it. When your change is ready, you open a pull request from a branch on your fork to the original repository, which by convention is called upstream.
Here’s the whole routine:
\n# 1. Click Fork on github.com/open-themes/vite-themes, then clone YOUR fork\ngit clone git@github.com:maya-okafor/vite-themes.git\ncd vite-themes\n\n# 2. Remember where the original lives\ngit remote add upstream https://github.com/open-themes/vite-themes.git\ngit remote -v # origin = your fork, upstream = the original\n\n# 3. Work on a branch, never on main\ngit switch -c fix-readme-typo\ngit commit -am \"Fix typo in installation steps\"\ngit push -u origin fix-readme-typoGitHub then offers “Compare & pull request” on your fork. Check that the base repository is open-themes/vite-themes and the base branch is their main. The CLI shortcut for steps 1 and 2 is gh repo fork open-themes/vite-themes --clone, which also sets up the upstream remote for you.
Leave “Allow edits by maintainers” ticked when you open the pull request. It lets maintainers push small fixes to your branch instead of asking you for every tweak.
\nThe original keeps moving. Bring its changes into your fork before starting each new branch:
\ngit fetch upstream\ngit switch main\ngit merge --ff-only upstream/main\ngit push origin mainBecause you never commit on your fork’s main, this is always a fast-forward. The Sync fork button on your fork’s GitHub page, or gh repo sync maya-okafor/vite-themes, updates the GitHub copy; you still pull it locally. (Plain gh repo sync with no argument updates your local clone instead.)
Before writing code, read the project’s README and CONTRIBUTING.md (setup, tests, style, whether an issue is required first) and its code of conduct. Search existing issues and pull requests; your bug may already be known or fixed. For anything bigger than a typo, open or comment on an issue and agree on the approach before writing code. Issues labelled good first issue are deliberately picked as starting points.
Then keep the pull request small, follow the project’s conventions even where you’d choose differently, make sure its tests pass, and answer review comments patiently. Maintainers are often volunteers. A focused, well-described pull request that’s easy to say yes to is the best introduction you can make.
\nThat completes the collaboration toolkit. In the last section you’ll pick up the habits that make all of this safe: undoing mistakes, keeping the repository clean, writing history people can read, and letting automation guard main.
origin is your fork and upstream is the original; you fetch from upstream and push to origin.","Before contributing, read CONTRIBUTING.md, look for an existing issue, and keep the change small and on its own branch."],"further":[{"title":"About issues","url":"https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/about-issues"},{"title":"About Projects","url":"https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects"},{"title":"Fork a repository","url":"https://docs.github.com/en/pull-requests/how-tos/work-with-forks/fork-a-repo"},{"title":"Syncing a fork","url":"https://docs.github.com/en/pull-requests/how-tos/work-with-forks/syncing-a-fork"}],"quiz":[{"q":"You cloned your fork of vite-themes. Which commands bring the original project’s newest main into your fork’s main?
git pull origin main","why":"origin is your fork, which doesn’t have the new commits yet. You’d be pulling from the copy that’s out of date."},{"text":"git push upstream main","why":"You can’t push to the original repository, and pushing sends your commits rather than fetching theirs."},{"text":"git fetch upstream, git switch main, git merge --ff-only upstream/main, then git push origin main.","why":"Correct. Fetch from the original, fast-forward your main to it, then update your fork on GitHub. The Sync fork button does the GitHub half."},{"text":"git clone the original again into a new folder.","why":"That works but throws away your setup and branches. Adding an upstream remote keeps everything in one clone."}],"answer":2},{"q":"You’ve found a bug in an open-source library and have a fix in mind that touches six files. What should you do first?
","options":[{"text":"Open a pull request straight away so the maintainers see working code.","why":"An unannounced large change may clash with plans you don’t know about, and can be closed unread."},{"text":"Email the maintainers privately with the patch attached.","why":"Most projects coordinate in public issues so others can see and help. Private email is for security reports only, if the project asks for it."},{"text":"Fork the project and publish your fixed version under a new name.","why":"That splits the community and leaves everyone else with the bug. Contributing the fix upstream helps everyone."},{"text":"Read CONTRIBUTING.md and search the issues; if none covers it, open one describing the bug and your proposed fix.","why":"Correct. Agreeing on the approach first avoids wasted work, and many projects require an issue before a pull request."}],"answer":3},{"q":"What’s the difference between a label and a GitHub Project?
","options":[{"text":"Labels only work on pull requests; Projects only work on issues.","why":"Both labels and Projects work with issues and pull requests."},{"text":"A label tags an individual issue or pull request; a Project is a view across many of them with its own fields, boards and layouts.","why":"Correct. Labels likebug categorise items; a Project arranges items (even from several repositories) into a table, board or roadmap."},{"text":"They’re the same feature with different names.","why":"Labels are simple tags on one repository’s items. Projects add custom fields, views and automation across items."}],"answer":1},{"q":"You opened a pull request from your fork’s main branch. While waiting for review, you start an unrelated fix and commit it to main too. What happens?
main.","why":"Correct. A pull request shows every commit on its branch. Give each contribution its own branch so changes stay separate."},{"text":"Nothing; the pull request froze its commits when you opened it.","why":"Pull requests follow their branch, which is why pushing to it updates them."},{"text":"GitHub rejects the push because a pull request is open.","why":"Open pull requests don’t lock their branches. The push succeeds and the pull request grows."},{"text":"The new commit goes into the original repository directly.","why":"You don’t have write access to the original. Nothing reaches it except through a merged pull request."}],"answer":0}],"exercise":{"kind":"choice","multiple":false,"options":["a","b","c","d"],"correct":["d"],"title":"Contribute a fix you can't push","prompt":"You cloned open-themes/vite-themes directly, fixed a typo on a branch called fix-readme-typo, and ran git push -u origin fix-readme-typo. GitHub answers:
ERROR: Permission to open-themes/vite-themes.git denied to maya-okafor.\nfatal: Could not read from remote repository.What’s the right way to get your fix to the maintainers without redoing the work?
\n","hints":["The error isn’t about your SSH key; GitHub knows exactly who you are.","You need a copy of the repository on GitHub that you are allowed to push to.","Your existing clone can talk to more than one remote."],"explanation":"You don’t have write access to open-themes/vite-themes, so no credential will make that push work. Fork it on GitHub, which creates maya-okafor/vite-themes. In your existing clone, rename the current origin to upstream (git remote rename origin upstream) and add your fork as origin (git remote add origin git@github.com:maya-okafor/vite-themes.git). Then git push -u origin fix-readme-typo and open a pull request from your fork’s branch to the original’s main. Your commit is reused as is.
git push --force -u origin fix-readme-typo.","why":"Forcing changes how a branch is overwritten, not whether you’re allowed to write. The push is still denied."},"c":{"text":"Email the maintainers and ask them to add you as a collaborator so you can push your branch.","why":"Maintainers don’t grant write access for a typo fix. Forks exist so anyone can contribute without it."},"d":{"text":"Fork it on GitHub, make the original upstream and your fork origin in this clone, push the branch to your fork, and open a pull request to the original.","why":"Correct. Your fork is a repository you can push to, and a pull request from it is how changes reach a project you don’t own."}}},"words":778,"readMinutes":4}