Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A simple git branching model

gist.github.com

Post reply on HN
Print view View original

151–158 of 158 posts

Re: A simple git branching model

#151

Post by _prometheus »

shawnps wrote: post #30

We 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…

> 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 and the committer presses the merge button on GitHub. Once the button is pushed, a build of master is triggered. If the build passes, the code is automatically deployed.

This isn't an unattainable utopia. It's what lots of teams are doing now. Try out continuous integration services (Travis or Koality).

And, given you have good instincts, ping me when you're looking for a new team ;)

Re: A simple git branching model

#152

Post by _prometheus »

eknkc wrote: post #53

In a similar model, I just commit hotfixes on the master branch. What is the negative implication of this? If I had a branch for them, those would just be merged back immediately with one commit anyway.

No rule is sacred, and your mileage will vary. For me, having a pull-request for the hotfix helps us run continuous integration tests, code-review, and ensure relevant people get notified automatically of the fix.

Re: A simple git branching model

#153

Post by _prometheus »

the1 wrote: post #16

do you rebase before accepting pull request or before publishing your feature branch?

Depends on how you want to do it. I'd rebase on top of master before publishing, _and_ before merging it in (accepting PR).

Definitely be comfortable with rebase before you try this though.

Re: A simple git branching model

#155

Post by Alphasite_ »

lambda wrote: post #83
tootie wrote: post #31

Earlier quoted context omitted.

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 com…

Well, why not a concept of 'soft' and 'hard' commits (or sub commits, or major and minor)? Let people do what they must, let the logic behind it stand, and give a nice clean history by ignoring the soft commits unless you explicitly access them?

Re: A simple git branching model

#156

Post by a3n »

sanderjd wrote: post #77
a3n wrote: post #15

Earlier quoted context omitted.

Because no one cares about an individual's doodles and false starts on a feature branch, or an exploratory branch off a feature branch, they only care about the final difference between before and after merge. Explorations are an unnecessary distraction.

I disagree that categorically "no one cares": https://news.ycombinator.com/item?id=6457243

I think phrases like "no one" should be understood as no one modulo a small number of exceptions that does not noticeably affect the majority trend. Always.

Re: A simple git branching model

#157

Post by sanderjd »

_prometheus wrote: post #146
sanderjd wrote: post #71

Earlier quoted context omitted.

> You need clean commits on the history to be able to understand the code later on. I think this whole debate hinges on peoples' view of that sentence. Sometimes clean history helps comprehensibility and sometimes it obscures things. I think the amount to which each is true varies author to author, reader to reader, and project to project.

> I think this whole debate hinges on peoples' view of that sentence. Prescient observation. How does clean history obscure things though? You mean as failed experiments get removed? Important things ought to be mentioned in commit messages. Relevant things to document can be showcased like "Tried X but it turns out Y is better because Z." I often find that code alone is not enough to describe why something did or di…

> I often find that code alone is not enough to describe why something did or didn't work.

Me too. And I also often find that commit messages alone are not enough to describe why something did or didn't work. Code and commit messages both help.

"Clean history" can obscure things when it leaves out information about the often messy process of creating the software. It's impossible to know ahead of time what information will and will not be useful when attempting to grok a piece of code in the future, so sometimes it makes sense to err on the side of more information, instead of less.

Re: A simple git branching model

#158

Post by djbender »

programminggeek wrote: post #67

I avoid rebase like the plague if I'm working on a team, and if I'm not working on a team I don't see the need for it much either.

Rebase is good for when you need to rewrite or clean-up history. For example: all those "WIP" commits you'll frequently see aren't exactly helpful. If you want to rewrite history of a branch that others are actively working on, well then you're going to have A Bad Time™.
Post reply on HN