Editing in the browser and pulling it back
Intermediate GitLab UI GitHub UI Git CLI
Why this matters
Someone reports a typo in the FAQ while you are on a phone, or on a machine with no Git installed. Cloning, branching and pushing for one character is out of proportion. Both platforms let you edit a file, commit it to a branch and open a merge request without leaving the browser, and the whole thing takes a minute.
What browser editing is good for
| Good for | Not good for |
|---|---|
| A typo, a broken link, a wrong number | Anything you should test before committing |
| A small documentation change reviewed by eye | Changes across several files that belong together |
| A quick fix while away from your own machine | Renaming or moving files (possible, but awkward) |
| Reviewing and applying a reviewer's suggestion | Anything where you want a preview beyond Markdown |
The limit is not technical, it is that you cannot run anything: no tests, no Markdown linter, no program. The pipeline runs after you commit, so a browser edit that breaks the build fails on the server rather than on your laptop.
The commit is real
The most important thing to understand is that a browser edit is an ordinary commit on an ordinary branch. It has your name, a message and a hash; the pipeline runs; a merge request can be opened. And your clone knows nothing about it until you fetch:
$ git fetchFrom https://gitlab.com/you/trailguide
216f956..01268bf main -> origin/main$ git statusOn branch main
Your branch is behind 'origin/main' by 1 commit, and can be fast-forwarded.
(use "git pull" to update your local branch)
nothing to commit, working tree clean$ git pullUpdating 216f956..01268bf
Fast-forward
docs/faq.md | 4 ++++
1 file changed, 4 insertions(+)That is the entire relationship: the browser made a commit on the remote, and git pull brought it home. Lab 2 walks this exact sequence.
How to do it
The terminal cannot edit files on the server; the browser is the point of this lesson. What the terminal does is collect the result:
$ git pullIf you have local work in progress, commit or stash it first (lesson 5.7), then pull.
Not needed for the browser edit itself, but two things help afterwards:
Turn on Git: Autofetch in Settings, so the status bar shows that the remote has moved without you asking. Then click the sync button to pull the browser commit down.
For editing on a machine that has VS Code but no clone, Git: Clone is usually faster than the browser anyway.
Same: Git → Fetch or Update Project (Ctrl+T / ⌘T) brings the browser commit into your clone. IntelliJ shows the incoming commits in the Git tool window's Log before you accept them.
GitLab has two editors.
Web editor, for one file:
- Open the file under Code → Repository.
- Select Edit, then Edit single file.
- Make the change. The editor has a Preview tab for Markdown.
- At the bottom, write a real commit message (replace GitLab's suggested one).
- Choose the target branch. On a protected
mainGitLab creates a new branch for you and offers Start a new merge request; leave that ticked. - Commit changes.
Web IDE, for several files at once: Edit → Open in Web IDE. It is a full editor in the browser, with a file tree and a Source Control panel, and it commits all your changes together.
- Open the file in the repository.
- Select the pencil icon at the upper right of the file view.
- Make the change. The Preview tab shows rendered Markdown, and Show diff highlights what you changed.
- Select Commit changes…. A dialog asks for a message and an optional description.
- Choose Commit directly to the
mainbranch or Create a new branch for this commit and start a pull request. On a protected branch only the second is offered. - Commit changes (or Propose changes).
For several files, press . on any repository page to open github.dev, a VS Code-like editor in the browser with a Source Control panel.
Common mistakes
- Keeping the suggested commit message.
Update faq.mdtells nobody anything. Write a real subject, with the issue number (lesson 5.4). - Committing straight to
mainwhen a merge request was expected. On unprotected branches the platform lets you; check the target-branch choice before committing. - Editing in the browser while you have local uncommitted work in the same file. The pull that follows conflicts. Push your local work first.
- Using the browser for anything testable. No tests run until the pipeline. For code, clone.
- Forgetting to pull afterwards. Your next local commit starts from an older base, and you meet a rejected push.
Try it yourself
Goal: make a browser commit on a branch and bring it into your clone.
- On your playground project's website, open
docs/faq.mdand edit one line. - Write a proper commit message, and choose to create a new branch rather than committing to
main. - Open the merge request the platform offers, then merge it.
- In your terminal:
git fetch,git status, and read the "behind" line. git pulland confirm the change is in your local file.
Expected result: step 4 reports behind 'origin/main' by 1 commit; step 5 fast-forwards and the file on your disk now contains the browser edit.
Show solution
Choosing a new branch in step 2 is what makes this a normal contribution rather than a direct commit to main; it is also what a protected branch would have forced. The fetch in step 4 proves once more that your clone learns nothing until it asks.