Question

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.

Answer 1

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.