When you have work that was done in parallel (in terms of history) it's fine to merge. If you want linear history, use the --rebase
option on the pull. Further, you can set your configuration so that pull does a rebase instead of a merge every time.
Commit published twice: Merge remote-tracking branch 'origin'
-
07-12-2021 - |
문제
I forked from a repository (upstream), then do my changes locally and push to my repo (origin).
To add to this, I do most of my work at my console, and today I did some on the laptop.
I pushed to origin on my console, then git fetch origin; git merge origin/master
on my laptop the next day.
What happened is that I took all the changes from the day before, committed them to my laptop, and pushed those back to origin. Now I have two sets of commits on my origin/master for the same work, once for the console, and once for the laptop.
I've read before that I should publish once, and though I'm certainly not considering altering this pushed history, I do want to avoid this whenever a lapse occurs between workstations. The commit history looks confusing.
I thought the --no-ff
option on git pull
looked promising, but most of the information I find for this topic is about keeping local branches in sync as master is being developed on by others.
해결책