3.3. Managing Files Within a Repository
Not every change to a repository needs a local Git client — GitHub's web interface can handle simple file edits directly.
💡 First Principle: Any file in a repository can be created, edited, renamed, or deleted directly in the browser, and each of those actions becomes a real commit — GitHub prompts you for a commit message and, on a protected branch, routes the change through the same pull request process as any other edit. This makes small fixes (a typo, a config tweak) possible without cloning anything locally.
Common in-browser file actions:
- Add file — upload one or more files, or create a new one directly in the editor
- Edit — GitHub's built-in editor, committed either straight to the current branch or via a new branch + pull request
- Rename / move — treated as a delete-and-recreate at the new path, still tracked as history
- Delete — removes the file in a new commit; prior versions remain fully recoverable in history
- History — every file has its own commit history, viewable independently of the rest of the repository
⚠️ Exam Trap: Editing a file through GitHub's web interface still produces a real commit with a real commit message — it is not a special "untracked" edit. On a branch with required reviews, it still has to go through a pull request like any other change.
Reflection Question: You fix a typo in a README using GitHub's web editor instead of cloning the repository locally. Does that edit show up in git log? Why or why not?
