Fix conflicts only once with Git rerere
medium.com
medium.com
I don't understand what other commenters are complaining about rebase and rewriting history, because this article is not about that, it's about not having to fix conflicts multiple times. This can be handy in a variety of situations. You might not need it, but every person/team has it's own way of working with Git. Rerere is just another tool that might help you in your workflow.
And to the people who are claiming that rebasing is hard, dangerous or a clean history is not necessary: Once you get it's not hard or dangerous, and a clean history really IS useful. Why are we using Git again?
- Being able to work together on a codebase (the history shows the changes)
- Code reviews for new features (the history of the pull request shows the changes the feature introduces)
- Being able to roll back to a previous state in case there is something wrong with the latest version (the history can help you decide where to roll back to)
And a lot of more reasons we use Git that have to do with the history. It is true it takes a little bit more effort to have a clean history, but in big teams/projects it's really worth it.
Don't rebase commits you have already pushed.
This sounds like a completely arbitrary rule to me. I just don't get why people try so hard to avoid merges, and instead go down the rebase route.
Rebasing isn't just a pain, it's rewriting history. It's potentially dangerous in a team environment. You can't distribute your rebased branch without a force push, and that risks two versions of the branch's commits getting into the repository, or losing someone's commits altogether. It's usually not worth the effort.
It also presumes a simplistic development environment. Typically, I see branches that fit into categories; let's name them master, develop, small-feature, big-feature, next-gen-architecture.
Small-feature branches can be rebased fairly easily. There's not many commits, they're most likely worked on by a single person so the history isn't distributed, and replaying the commits isn't too onerous.
Big-feature branches are a little more tedious. This is where rebasing starts to become a pain; the big feature may have touched code that has since changed from commits of a few small-feature branches.
Next-gen-architecture is where it all falls apart. Trying to do a major refactor while simultaneously keeping customers happy with smaller features is a fact of startup business, if not most businesses. Rebasing becomes a multi-hour exercise because there are hundreds, if not thousands of commits to replay. And everyone on the team has this branch, and there may be sub-branches of it that are destined to be merged into it. All the sub-branches need to be rebased too.
>> This sounds like a completely arbitrary rule to me. I just don't get why people try so hard to avoid merges, and instead go down the rebase route.
I agree, I think that graph looks fine. I often end up with this, not just to avoid a big merge later, but because functionality I'm working on can benefit or depend on other work done on the main branch.
Git merge squash essentially takes a diff of your feature branch and master and applies the diff as a single commit. See http://stackoverflow.com/a/25387972/1935918
You lose the history of the feature branch, but we don't want that history anyway, since once tests are passing and the branch has been reviewed, we treat it as an atomic unit. That is, we might revert the whole commit, but we're not interested in reverting part of the commit.
A single line change can be linked to a relatively small commit, it's extremely useful to figuring out the "why" of something. Having one commit for an entire feature would make that utility completely disappear
When I want to share my commits, I do my rebase first, do a fast-forward merge in the shared branch (with or without a merge commit, depending on whether or not I need to group my commits), and then I push the shared branch. After that my local branch is rooted at the tip of the shared branch, and prior history never gets rebased again.
Merging master into a shared feature branch requires different techniques; we don't use rebase for that. Instead we coordinate: everyone gets their work into the feature branch (or takes responsibility for anything they're not ready to commit yet), and one person takes on merging master into the feature branch, fixing conflicts, and pushing the result back to the shared branch. Everyone else pulls, rebases any local work they still have, and we move on. When it's time to merge the feature branch into master we do the same thing, but no local work is allowed to be held back, and the person doing the merging will also merge the final feature branch back into master.
Luckily I'm in a small company with not too many developers. I can see the coordination required for what I just described getting more and more difficult as the branches get bigger, last longer, and have more people working on them. When you get up to that scale the Linux Kernel approach of breaking the project into largely independent sub-projects with different owners responsible for merging their own parts is probably the best approach. That makes the coordination manageable.
I'm so tired of this!! Of course you never rewrite history on a public branch!! Of course rebase is fantastically helpful on a private/feature branch where you are doing development, before you do your final push to the public branch!!
Can we stop with these tired, old tropes please??
I do commercial closed-source development; there is no public branch to the whole world. OTOH, all feature branches are public to the team; only trivial features involve a single developer. So your assertion doesn't seem well-formed to me.
Further: The distribution of code and feature responsibilities in a team of full-stack engineers is fluid. Depending on the day, any person might be working on a feature, and the person previously working on it might not even be in the office. It's a general policy where I work to push your branches before close of business.
To anyone other than you. If other people are involved, then think very seriously whether or not rebase should be used. Almost in every case it should not be.
I'm on your side. My objection was to the latter statement, not the former. The basis of my objection to the former was (in part) because of the problems with rebasing when a branch is distributed. The idea that the only merges that occur are merges of finalized branches seemed very naive to me.
If you don't work with private branches, it's not surprising that you don't see any value in rebasing which is mostly useful for private branches.
In fact, if you don't have private vs. public scenarios, it's not really clear whether you need a distributed version control system. But that makes sense, DCVS were developed for OSS after all.
If I create a branch which tracks a remote branch and make a commit to it, my local branch is "private" and the commit is "private. However, I can push that "private branch" to other developers, and then it becomes public.
Exactly that. An unpublished branch.
The benefits of a DVCS are far broader than that. Development on code that is stored on individual developer's machines is fundamentally distributed. Removing the requirement to be connected for any interaction with the system is major. Deferring conflicts until merge time rather than using file locking is major. There are loads of benefits from DVCS that have no requirement for an important distinction between public and private.
Feature branches are throw-away, this is a big part of the zen of Git.
I do commercial closed-source development; there is no public branch to the
whole world. OTOH, all feature branches are public to the team; only trivial
features involve a single developer. So your assertion doesn't seem well-formed
to me.
This makes it easier to manage public rebases, because you only affect those devs working on the feature, but more importantly it means that you still get the security because your release repository always maintains the integrity of its history.
The problem is that git doesn't track what "public" means. There was a proposal to work on this for GSoC 2012[1], but nobody picked it up. This concept is called "phases"[2] in Mercurial, which are a building block for Evolve[3].
In Mercurial, it'ss possible to safely rewrite commits, and it's also possible to safely propagate your edits to other repos. Git would have to grow something like changeset evolution to make this completely safe and to be able to deprecate `git push --force`. There could be a safer alternative that does not require any forcing.
[1] https://github.com/peff/git/wiki/SoC-2012-Ideas#published-an...
At any point, we have at least 3 different feature branches, which can be relatively long running (minimum 1 week), this is because we have a range of products sharing the same base platform.
So when come merge time, well ... we merge and do not rebase master before doing that (well, technically we merge on an RC branch but that still applies). If we would rebase, we would have 2 teams that need to go through a potentially painful rebase process.
Besides, on each branch, there are usually at least 2 developers, so it would be even more chance to have a problem for the developer that is not doing the rebase.
Well, all of that to say that we just do a merge (with no squashing ...I really dislike a big commit, even more if it shares some frontend and some backend stuff in the same commit).
I think I might be missing something though, I have never understood why having a clean history (when the real history isn't clean) is important.
If you've got huge branches with scary merges, isn't the problem that you have huge long lived branches? Why does it matter that my graph shows when I actually did merge things?
I usually hear a git bisect argument around this, but are there good examples where it becomes a problem? Bisect lets you specify when to skip a commit, so you can be as selective as you want with it.
Lots of people complain about problems rebasing, and I've repeatedly seen issues where people mess up and that causes more pain when just merging seems to work perfectly fine. It seems like a lot of work, effort and time to avoid potential issues later (and even then I'm not sure what those issues are).
This isn't rhetorical, given so many people have strong opinions on this I assume I'm missing something important.
I say this having gone from a mercurial user that produced pristine commit histories to a git user that makes dirty, nasty histories.
I've worked in projects that always keep a clean history. And I've worked in projects where developers don't bother cleaning up history before pushing. And in every non-trivial project that follows the latter I've always hit cases where I try to track down something through the history only to find that the history doesn't capture the meaning of the code. This is not just bad merge behavior, but also things like lumping unrelated changes together into a single commit.
Even something just as simple as reading recent history to keep up with the changes being made to the codebase is significantly simpler if developers are diligent about keeping a clean history. For example, the Rust project has a lot of activity, but also has a strict code review policy that means that nearly all commits are done with a clean history (very occasionally, long-lived branches are allowed through that have control merges, but those are rare). And as a result, even though I no longer have the time to actively contribute, I've still managed to keep with every non-trivial change made to Rust merely by periodically reading through the history since my last pull. I can't imagine trying to do that if the history weren't clean.
Instead, breaking up the feature into logical pieces allows you to documented every step properly in a separate commit message.
If you properly understand what you're submitting for review, then it isn't really much work at all. It's even easier if, during original development, you commit often. But you can always split commits up during rebasing, too.
In addition, it is also useful when merging a feature branch turns out to be a problem later on. Reverting a rebased merged feature branch is very easy, without having to think about if there any issues with mid-branch merges and so on.
With a normal merge, git bisect will likely point to the merge commit as the first commit that introduced the behavior, which was the first time these 2 branches ever interacted. This means resolving inconsistencies after the fact, somewhat similar to "eventual consistency". It is more coarse-grained, can be harder to reason about, but may scale better (no serialization).
With a rebase, git bisect will point to one of the rebased commits, each of which already interacted with the branch coming before. Rebasing is sort of similar to the situation where DB client retries a transaction because the DB doesn't know how to serialize 2 transactions. It is more fine-grained, can be easier to reason about, but may have problems scaling, and may sometimes be tedious.
A similar problem is 'When did this break?', where you do the whole bit with "well it was working before here, but not now, it must have changed somewhere in the middle" then you're doing the binary search of the changesets between etc.
The solution is called "bisecting a problem" as in cutting in half repeatedly. The git command/tool for this is:
http://git-scm.com/docs/git-bisect
Using these commands, the system checks out versions in a binary search pattern, and asks you if this code is broken or not, then after some iterations tells you which commit broke things. Really handy. I suspect with some scripting if you could create an automated test you could wire it up to be completely automated as well.
I thought it was best practice to merge master into your branch now and then to keep it up to date and avoid one big messy merge at the end. What is the disadvantage exactly?
I'd be great if there was a strategy for fixing conflicts with VS files.
I'm not sure I follow the author's issue with control merges though. Apart from a dogmatic statement that merges should be final (says who), what problems do control merges create?
(sln files aren't really XML, but they're XML-like in their structure. I've had fewer problems with them than the other files.)
The second issue is the way Visual Studio modifies these files: it reads and parses them into a DOM tree, makes changes to the DOM, and then serializes the DOM back out to the file. So a small change in one part of the project causes the entire file to be re-written, and it often gets restructured in the process. I've found this to be a bigger problem when different developers are using different versions of Visual Studio; at my company we've had 2010, 2012, and 2013 all in use at the same time on the same projects until everyone upgraded. (And we had good reasons for not upgrading everyone at once.)
I guess there's a third reason: most .NET developers never look at these files directly; for the most part they are only modified through Visual Studio. So, although they're just text files and conflicts are resolved the same way they're resolved in code, that's made more difficult by not knowing what the files are supposed to look like or what the correct resolution should be. The sln files are particularly annoying in this regard because they're about 80% Guid strings and 20% readable text, so it can be really hard to understand the diff.
When I started working with .NET, I had to learn all about these file formats when I started running into conflicts in them, and now I'm comfortable fixing conflicts and often editing them directly. I've helped most of my team gain the same comfort level, so we don't have problems anymore. The conflicts, when they happen, are just annoying now.
Thanks!