An edit every server needs is recorded as a commit and sent to the shared repository.
A commit from the previous lesson (git add and git commit -m) lives only in this working copy: after it git status says “ahead of 'origin/main' by 1 commit”. git push sends the branch's new commits to origin, and other copies get them with their own pull. After the push status says “up to date with 'origin/main'” again.
Send the edit to the repository
The team decided to raise the lab-site upload limit to 50m on every server. In /etc/nginx/conf.d change the limit in lab-site.conf, record the edit as a commit and send it to the /srv/git/lab-site.git repository so the other copies can pull it.
Goals · 0 of 2
- Record the new limit as a commit not done yet
- Send the commit to the shared repository not done yet
The repository accepts a push only if your commit continues its history. If someone pushed a commit before you, git refuses: ! [rejected] main -> main (fetch first) or (non-fast-forward). The other commit is not lost and not overwritten — get it with pull first, then push again.
When both you and the repository have new commits, git pull asks how to join them: “Need to specify how to reconcile divergent branches”. git pull --no-rebase --no-edit joins them with a merge commit and a ready-made message, and push goes through after it (in the Wiki).
You committed an edit, and git push answered “! [rejected] main -> main (fetch first)”. What do you do?
-
reset --hardthrows your commit away, leaving nothing to push. You would have to redo your edit. -
nginx has nothing to do with the refusal: the repository rejected the commit because it holds commits you do not have.
-
--forcereplaces the repository's history with yours, and the colleague's commit disappears from the shared branch. The refusal is there to protect it.
The repository accepts a push only if your commit continues its history. pull first gets the other commits, then push goes through.