[fla]

For some time now, we use the rebase workflow. (create your branch, do some work, rebase on master, push).

It is a great way to have a clean linear history.

But it makes git pull 'illegal' because it does a merge implicitely.

That's tipically something I didn't think about the first times I used git.

[brandmeyer]

> It is a great way to have a clean linear history.

Why is this considered by so many people to be a Good Thing? Engineering is an inherently messy human process, and the repository history should reflect what actually happened. To that end, I've been advocating a merge-based workflow instead:

- The fundamental unit of code review is a branch. - Review feedback is incorporated as additional commits to the branch under review. - The verb used to commit to the trunk or other release series is 'merge --no-ff'.

Under that model, merges are very common, particularly merges from the trunk to the feature being developed. But that's OK, because its what actually happened. When most people perform a 'rebase', they are actually performing a merge, while dropping the metadata for that merge.

[the4dpatrick]

Before reading more about rebasing, I wouldn't have an opinion here, but like most things in programming I think it's a matter of philosophy. Do we want the history to be "record of what actually happened" or "story of how your project was made." [0]

I see merits in both approaches: Rebase seems to be good when you want to focus on the project minus the process, while merging seems to be good when you want to know the process behind the project. For larger projects with multiple contributors, I think the merging approach is better because of the process visibility. For smaller projects with one or two developers, a rebase approach could be "cleaner" when looking through the logs later on.

I'm interested to hear what other's opinion on the topic as well.

[0] - https://git-scm.com/book/en/v2/Git-Branching-Rebasing#Rebase...

[fla]

It is an interessting analysis. I think you're right saying that its a matter of philosophy after all.

In my experience, the clean linear history can be important when you build a product which is going to be certified since the developement process is key to obtain the certification.

Also, I like the fact you can always reorganize your commits before rebasing, making them more atomic / cleaner.

[grayclhn]

    git pull --rebase

doesn't merge implicitly and

    git config --global pull.rebase true

will set that as the default `pull` behavior.

[gechr]

Note that

  git config --global pull.rebase true

was added in v1.7.9 - if you're using an earlier version of Git for whatever reason, the config you should be setting is

  git config --global branch.autosetuprebase always

[fla]

Didn't know that. Thanks