If you're looking for an automated tool to do this, take a look at gerrit. I used it successfully at my last day job. It basically enforces this model. The quality of our commit history changed quite dramatically.
A simple git branching model
81–90 of 158 posts
Re: A simple git branching model
#82We used a very similar model to this at my last job, and I'm struggling to get my current team on board with this type of process. I think the main problem is that people don't trust continuously deploying master because there aren't enough tests. In my ideal world, every commit is tested (with Jenkins, Travis, Buildbot, etc), and then if the PR includes tests for the code and the build passes, the reviewer says LGTM…
You can do this with Travis' new deploy feature.
Re: A simple git branching model
#83Earlier quoted context omitted.
When I am working on a feature branch, I often find myself committing experiments, that I possibly undo later in the branch. I don't always focus on making "incremental, atomic" commits, because I am usually focused on the code. When the feature is done (but before I merge it into master), I will usually go through and clean up my meanderings, and turn them into "incremental, atomic" commits, so that my teammates don…
If you rebase aren't you destroying that history of experimentation? I feel like this is destroying the whole idea of a VCS as a safety net and making developers self-conscious about something that supposed to tolerant of mistakes.
Cleaning up your history before merging is important. For one, before you merge you should usually have someone do code review. No one wants to do a code review on a branch that has a bunch of false starts, typo fixups, debug print statements being added and removed, and so on. Code reviewing a branch that breaks something and then fixes it three commits later is a real pain; you sit there puzzling over the first commit, wondering how it could possibly work, and writing up a big explanation for why they need to fix something, then you go on to a later commit and realize they already fixed it.
Furthermore, dirty branches lose you a lot of the power that having a good, clean history gives you. When you do a blame on a line of code, to figure out when the last change was, do you want to see the "fix whitespace to match style guide" commit that someone insert in the branch at the end, or the actual meaningful change that occurred earlier? If you don't squash your commits to deal with these kinds of issues, you lose a lot of the power and convenience that good history gives you.
There's more. One of Git's most powerful tools is bisect, but even in a VCS without an automated bisect, doing it manually can be useful to (I've done this in SVN before). If you have a regression, but have no idea what caused it, it can be very useful to bisect your commits; find a known good version and a known bad version, then go to the commit halfway in between, test that, and depending on whether that commit is good or bad, test the one halfway between that and the known good or known bad commit. Keep doing this until you find the commit that broke your code. But this process is seriously impeded if you have a bunch of half-done commits that implement a part of a feature but break something else that's fixed up three commits later.
The "history of experimentation" nature of VCS history is just not all that interesting. Think of your VCS history more as an extended form of comments, that document why everything is the way it is. If you actually wrote comments on every line describing why you had changed it in a particular way every time you changed it, your code would wind up being more than 90% comments in not too long. Most of the time, you don't need to see this; but when you are left wondering "hmm, why is this the way it is?", good history is invaluable. The experimental changes in between aren't all that useful; if you got any information from them, then feel free to summarize that in the cleaned up commit message after you've squashed them out.
Now, that's not to say that you should always produce perfect history while working on a branch. Feel free, when you're in exploratory coding mode, to make lots of checkpoint commits, experiments, and so on. Just clean it up before you present it for review and merge. The nice thing about Git is that you have your own local branches that no one else ever has to see, clean things up quickly and easily with "git rebase -i", and present a much nicer history when it's ready for merge.
Re: A simple git branching model
#84Earlier quoted context omitted.
I silence the noise before merging on a public branch by squashing the "thinking commits" on my private branch. What remains is a clean history of commits. You will not find the oscillating commits on the public branch but you will find them on my private (local) branch. So you do commit early and often, just that nobody else sees your commits until the feature is complete and working. And then only after you rearran…
Company policy: you can't keep branches just private, locally, because they're not backed up. (That's just how it is at my company. PCs aren't backed up, central repos are.)
How do you enforce that with Git? Any time you create a branch, it's local until you push it.
But anyhow, just give people private repos on the server. What I do is push my private WIP branches to my home directory on the server, and once it's ready for code review and merge, push it to the central repository.
Re: A simple git branching model
#85Earlier quoted context omitted.
If people pull from a random github branch I think it is their problem. They should pull only from what you declare as public branches with stable history. I keep on github only the master branch and publish the feature branch only when it is ready. After the maintainer merges the feature branch, I delete it from github.
I am, of course, talking about private GitHub repos used within a single company, and not about random people pulling down branches, but rather team development.
My point is that people should be branching from stable branches.
From your explanations, I understand your scenario is this: a private (shared by a team) repository on github. You work on your PC and then push on the shared repository on github.
If this is the case, you should push only when the branch is stable. If people really need those branches and you rebase them, you jut make it hard for them.
Either you stop rebasing what they consider public branches or you reconsider what are your public branches.
Re: A simple git branching model
#86I still don't understand why everyone has this misguided quest for a clean history. An accurate history is much more important. Rebasing destroys historical information. I can't really see any advantages of rebasing when a merge does the same thing but leaves two things rebasing does not: 1) a point to rollback to if things don't work out, and 2) an explicit entry of when your branch was brought up to date with maste…
Much in the same way visiting a museum is much more useful for understanding the past than visiting your grandma's attic, I think a curated history is much more useful than an accurate history. When someone says a clean history, I think they're saying a well-curated history. You don't submit your first draft almost anywhere else, why do you think nailed it the first time writing your commits? Sometimes you don't get…
Well, that analogy is OK but there is another analogy which comes to mind: keeping track of everything you do may have very useful future side-effects. As any lab researcher will tell you, keeping a strict log of anything you do is the way to both knowledge and reproducibility.
So git history is not necessarily "human history" but "engineering history" and as such, may be much more important than you think and "curating" it may be a mistake.
Re: A simple git branching model
#87Earlier quoted context omitted.
Noise vs Information on a shared project ? Imagine we are both working on a project. I don't care to know that you merged 3 times from master yesterday before pushing your feature. Also I don't care to know details like you forgot to put a config file in your first commit and had to do a second one, or that it took you 3 commits to have the spelling alright in the UI. Mainly that information is useful to you. It is a…
I'm incredibly new to Git, but actually destroying the history seems like a crude solution for a sophisticated tool like Git. Couldn't there be some way to just tag the "main" commits and mark the dead ends as "extraneous" rather than destroying them? And then have your history-viewing tool hide/squash the unmarked "invisible" commits by default and only expose them when specifically requested? I mean, it seems to ma…
This! I have been thinking for a while that this whole weird business about rebasing and 'clean' history is really a response to a shortcoming in our tools, which don't give us a way to distinguish from 'small' incremental, work-in-progress, historical-record-but-not-that-interesting commits, and 'big' significant, feature-completing commits.
In Mercurial, you can kindasorta have this if you do all your development on named branches, and only merge the named branches back into the default branch at these significant moments. Then, you can merge willy-nilly, without rebasing or otherwise destroying or lying about history, and distinguish ignorable work-in-progress merges from significant feature-complete merges by which branch they were on. Most query commands let you filter by branch, so you can easily do that.
For those not familiar with Mercurial, the difference that allows this is that Mercurial permanently records the name of the branch a commit was added to. That means there is an observable difference between merging A into B and merging B into A. This is not universally agreed to be a good feature, but it does allow this particular approach.
Then you just have to choose between having a single shared development branch, a branch per developer, a branch per story, a branch per task, etc, and come up with a coping strategy for any resulting proliferation of branches.
Re: A simple git branching model
#88Earlier quoted context omitted.
As long as your final commits are logical you don't lose anything. You need clean commits on the history to be able to understand the code later on. During code review at a later time, the history of the experimentation is useless once you find several commits that touch the same code before settling on a final version.
> You need clean commits on the history to be able to understand the code later on. Really? That seems like an extraordinarily obtuse way to understand code. I would think comments directly the source files would be more useful. Commit history shows how they arrived at that result and that's what I would rather see there.
What do you think is easier for the next guy?
1) three commits that do:
- a = 1;
- a = 7;
- a = 3;
or
2) one commit that says:
a = 3;
My point is that experimentation is slightly different from changing your mind about the whole implementation. It is the same as writing your homework. You have a separate piece of paper where you make your experiments.
Re: A simple git branching model
#89Earlier quoted context omitted.
Why do you care about the history of dead-end experiments polluting the history of the specific final features being implemented and incorporated into the mainline?
I see both sides of this, but on my own team, where we are all meant to be experts on the project, I really like to be able to see the experiments, because there's a reasonable chance I'll be trying something similar to or perhaps inspired by those throwaway experiments at some point. I think there is a different trade-off in open source projects, where it's more helpful to have a history that isn't confusing to newc…
I end up with a lot of "Interim commit on foobarbaz" because I'm leaving work and want to push my code just-in-case. Refolding those into "foobarbaz: feature 1" is a lot nicer.
Re: A simple git branching model
#90Earlier quoted context omitted.
> You need clean commits on the history to be able to understand the code later on. Really? That seems like an extraordinarily obtuse way to understand code. I would think comments directly the source files would be more useful. Commit history shows how they arrived at that result and that's what I would rather see there.
What do you think is easier for the next guy? 1) three commits that do: - a = 1; - a = 7; - a = 3; or 2) one commit that says: a = 3; My point is that experimentation is slightly different from changing your mind about the whole implementation. It is the same as writing your homework. You have a separate piece of paper where you make your experiments.
Not to mention that in practice, if this sort of history cleaning is forbidden then people will just attempt to not commit those first two lines, meaning that they are not getting the full benefit of version control.