How to push/pull Git rebase
Solution 1
Remember that git rebase
replays changes and creates new commits. By rebasing and forcing pushes all over the place, you're going against the grain of the tool. Note how the "Recovering from an upstream rebase" section of the git rebase
documentation begins (with added emphasis):
Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream's point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.
Even though you're the sole developer, you'll still be others (from the perspective of one repo) when working in other clones. As you've seen, this workflow is a hassle.
Let your changes cook in branches. When a branch is ready for primetime, then rebase, merge it into master, and delete its topic branch. Your life will be easiest if you keep branches' lifetimes short and their scopes narrow.
Solution 2
I always make sure I commit and push (-f) everything from any machine I leave.
When I arrive at some other machine:
git fetch -v
git checkout mybranch # Already checked out with old HEAD
git reset --hard origin/mybranch
This works well because I know the other "me" at different computers consistently commits and pushes before I leave (And therefore there are no unpushed changes on the machine I arrive at)
Wernight
Video games / applications / website developer in C++ / C# / Python / PHP using UML, Agile/Scrum, and Unit Testing. From software implementation to business talk, passing by project management.
Updated on February 11, 2020Comments
-
Wernight about 4 years
I'd like to use
git rebase
so as to cleanly merge a feature in the master branch (in less commits or at least at the top of the change log). Note that I'm the only one working on the repository.After reading Git workflow and rebase vs merge questions, I found
git rebase
would be pretty nice and like Micah I'd like togit push
rebased changes simply because I'm working on them from different places (ex: my notebook, my home, another PC somewhere...)So here are two solutions (to the bi-directional ugly merge):
- Using
git push -f
to push, and then pulling on other machine, but how to cleanly get the latest version on other machines? - Using merge to merge master changes to the feature branch, git push/pull, and once mature, do a single rebase (in one or more commits cleanly)
(2) would be like below:
git co -b feature-a ... change files git push origin feature-a ... moving to another PC git pull origin feature-a ... change files git merge master ... change files (not the "special rebase") git rebase master git co master git merge feature-a git branch -d feature-a git push origin :feature-a
Which solution do you think would work? I haven't tried either of them so far (mostly by fear of making my log more messy).
- Using
-
Wernight about 14 yearsSeems like option (2) in my suggestions.
-
Wowbagger and his liquid lunch over 12 years"Let your changes cook in branches." I don't understand this comment. He's already using topic branches for new changes. The heart of the question seems to be how to combine remote branches and rebasing without annoying everybody around you.
-
Coder Guy over 8 yearsCurrently I create a patch of my changes and transmit the patch to the next machine I will be working on. My personal rule is to only commit code that cleanly compiles and also passes all of the tests. However this is quite a pain and I've thought about your approach quite often. On the other hand, doesn't this muddy the history / reflog on the machines?
-
rvazquezglez over 8 yearsThis is a really bad practice if you are working with someone else.
push -f
deletes the others story and forces them to rework.