…conflicts can be easier to deal with during merge than the more numerous, smaller conflicts during rebase.
Record a merge commit when a feature lands into master
After working on a feature/topic branch, merge it in master like so: git merge --no-ff feature
The --no-ff flag ensures there will always be a merge commit , even when technically not necessary. Merge commits are useful because they convey the following information:
where do changes come from (in this case: the "feature" …
…wide-ranging refactoring project. Other developers still need to be able to do their work, so that daily rebase may be an exercise in frustration as they add new code that needs to be fixed.
Branching by Abstraction
1. Introduce a flag controlling whether the old or new implementation should be used.
2. Add the new implementation …
When you switch branches or rebase, Guard may detect changed files and cause their tests to run.
If you save one file while another test is running, it's queued up. This means that a series of small tweaks can cause a bunch of tests to run, whether you want them to or not.
Sometimes, Guard gets the idea that you probably want to run all the tests, when you really don't.
Also, sometimes Guard's file detection gets choked up for whatever reason and won't run tests …
Rebase to the rescue
When running git pull we need to rebase, and so to the first way to avoid merge commits...
git pull --rebase What's happening here? Git will rewind (undo) all of your local commits, pull down the remote commits then replay your local commits on top of the newly pulled remote commits. If any conflicts arise that git can't handle you'll be given the opportunity to manually merge the commits then simply run git rebase --continue to carry on replaying your …
Rebase is your friend Sandofsky on the preferred and keeping history linear: workflow
Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable.
Always be measuring How on just about everything. uses to collect metrics
The times be changing Deploying: Then & Now .
Of course …
Rebase the "future" branch with current master.
Tag repository with "future-freeze" to reflect the point in time where the cookbooks are now.
Create a "future-freeze" branch at this same point in time. This is where users who use the GitHub repository as a whole repository, or sub-module should be updated. As the name implies, this will be frozen, and we won't actively maintain it.
Merge the current working branch, "future" into master. This …
Rebase topic branches just before merging and deleting them (and let other people know the branch is officially dead so they don't keep committing to their local copy)
Why go through the trouble of all this rebasing? Won't we be losing history? Well yes, rebase vs merge is always a tradeoff. For a long time I thought it was basically a wash: readability in exchange for precise history. However as I came to understand the tradeoffs things kept shifting towards rebase.