Master Git No‑FF Merges, Remote Pushes, and Effective Branch Strategies
This guide walks through disabling fast‑forward merges with --no-ff, demonstrates the full commit workflow, shows how to push changes to a remote repository, resolves common push errors, and outlines a practical branch management strategy for stable master and development branches.
1. Using --no-ff for a regular merge
Git defaults to fast‑forward merges, which discard branch history after deletion. To preserve branch information, disable fast‑forward with git merge --no-ff, which creates a new merge commit.
Step‑by‑step workflow:
Create and switch to a dev branch:
Modify readme.txt on dev :
Commit the changes:
Switch back to master :
Merge with --no-ff and a message:
git merge --no-ff -m "merge with no-ff" devRunning git log now shows a merge commit, preserving the branch history, unlike a fast‑forward merge which appears as a linear series of commits.
2. Pushing to a remote repository
After merging, push the changes to the remote server with git push. If you encounter the error “RPC failed; curl 52 Empty reply from server”, it is usually due to insufficient HTTP buffer size or unstable network.
Solutions:
Increase the HTTP post buffer: git config --global http.postBuffer 524288000 Disable compression: git config --global core.compression -1 Adjust trace settings (optional for debugging):
export GIT_TRACE_PACKET=1 export GIT_TRACE=1 export GIT_CURL_VERBOSE=1These configurations can also speed up cloning operations.
Basic push syntax:
git push <remote> <local-branch>:<remote-branch> git push --all originpushes all local branches; if the remote is ahead, Git will require a pull before pushing.
Use --force only when you are certain, as it overwrites remote history.
3. Branch management strategy
A practical workflow for team collaboration:
Master branch: always stable, used only for releases.
Dev branch: unstable development branch; when a version is ready, merge dev into master for release.
Feature branches: each developer works on their own branch off dev and periodically merges back into dev.
The overall branch diagram looks like this:
By using --no-ff merges, the history clearly shows when merges occurred, making it easier to trace changes compared to fast‑forward merges, which hide merge points.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITPUB
Official ITPUB account sharing technical insights, community news, and exciting events.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
