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

121–130 of 158 posts

Re: A simple git branching model

#121

Post by coherentpony »

jlgreco wrote: post #109
coherentpony wrote: post #73

Earlier quoted context omitted.

>Because clean history is easier to bisect. While this is often true, `git rebase` changes your commits. Your history is now a lie . I've been in the situation where a `git rebase` ended up breaking commits. It's possible to merge broken history with `git rebase`. Only a `git merge --no-commit` will give you the opportunity to tweak the merge commit so that the resulting merge isn't broken.

Time is relative and history is only what has been observed. You only rebase code that has not been seen by others, so the code that was rebased was never history at all, as far as anybody else is concerned. I don't think anybody ever recommends rebasing public code. There is a reason for that --force flag on git-push advises the user to use with care. I mean, I could configure my development setup to automatically c…

I'm not saying to never rebase. Rebasing has its merits. It's not always the best tool for the job.

>I don't think anybody ever recommends rebasing public code.

This very article says it's acceptable to rebase a public feature branch.

Re: A simple git branching model

#122

Post by reyan »

dreamdu5t wrote: post #112
denis1 wrote: post #101

Earlier quoted context omitted.

man, do I agree with you... I'm new to git, our whole company is... Every time I have to go through history, it is one big mess with a lot of intermediate stuff. It is a pain to work with.

So stop committing non-workable intermediate stuff and finish what you're doing before committing. I fail to see how it's "a pain" to have a history of everything done. If you want to mark new features or releases, use tags for that.

You can easily squash those experimental commits and have "incremental, atomic" commits in history. What it gives you is the freedom with a clean slate after each commit. And no stashing doesn't work because the next experiment might depend on the last one. Not happy? Interactively rebase HEAD~n and get rid of all the experimental stuff. Changed your mind? Git reflog is your friend.

Re: A simple git branching model

#123

Post by sofal »

dreamdu5t wrote: post #112
denis1 wrote: post #101

Earlier quoted context omitted.

man, do I agree with you... I'm new to git, our whole company is... Every time I have to go through history, it is one big mess with a lot of intermediate stuff. It is a pain to work with.

So stop committing non-workable intermediate stuff and finish what you're doing before committing. I fail to see how it's "a pain" to have a history of everything done. If you want to mark new features or releases, use tags for that.

No, you should never be afraid of committing anything you have at any point in time. Git works as a development tool as well as a central VCS. As long as you have committed something, it will be restorable in case you overwrite it or delete it. Telling someone to wait before committing is a bad idea. They may get a lot of work done and then inadvertently lose it somehow, permanently. Instead, you should commit often and then use interactive rebase later to clean things up. You want to be able to have the freedom to switch branches, navigate history, and work on multiple features/bugfixes at the same time. You're restricting your ability to do these things if you wait too long to commit, and you're increasing the danger of losing your work.

Re: A simple git branching model

#124

Post by jlgreco »

coherentpony wrote: post #121
jlgreco wrote: post #109

Earlier quoted context omitted.

Time is relative and history is only what has been observed. You only rebase code that has not been seen by others, so the code that was rebased was never history at all, as far as anybody else is concerned. I don't think anybody ever recommends rebasing public code. There is a reason for that --force flag on git-push advises the user to use with care. I mean, I could configure my development setup to automatically c…

I'm not saying to never rebase. Rebasing has its merits. It's not always the best tool for the job. >I don't think anybody ever recommends rebasing public code. This very article says it's acceptable to rebase a public feature branch.

> This very article says it's acceptable to rebase a public feature branch.

  # optional: feel free to rebase within your feature branch at will.
  #           ok to rebase after pushing if your team can handle it!
It says that rebasing a feature branch is fine if it hasn't been pushed (ie, if it is not public). If it has been, then it is only okay to rebase it if everybody else on your team okays it, which is just common sense. If nobody cares then... nobody cares.

The problem with the article is that it's wording is imprecise.

Re: A simple git branching model

#125

Post by gmartres »

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…

> 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?

    git blame -w # works with git diff and git show too
(You might also be interested in --word-diff=color for git diff and git show)

Re: A simple git branching model

#127

Post by purephase »

wting wrote: post #103
rsanheim wrote: post #94

Interestingly enough, most folks working on GitHub.com don't use this model. We actually use a simpler model, and usually merge to our feature branches rather than rebase. I'm not sure if Zach's latest talk(s) goes into this level of detail. I think a big part of the reasoning is because we tend to push up branches really early to open PR's and get discussion going. And of course rebasing public branches generally le…

I think it depends on how public and how many contributors you have to a feature branch. I think author has the assumption that there is typically one dev per feature branch. Once a feature branch is being worked on by multiple devs (and hence multiple feature branches forked off), it is a public branch and should use a merge based workflow.[0] I personally use a rebase workflow on private branches before merging sin…

This is exact same workflow I use. If it's a feature branch that I'm working on locally, then rebase -i is my friend as I can squash commits. But, I rarely stay in a local branch for longer than a day or two for fear of losing work and no developer is an island. The second it is shared, it's merge only.

Rebase conflicts always cause more grief than it's worth.

Re: A simple git branching model

#128

Post by dreamdu5t »

sofal wrote: post #123
dreamdu5t wrote: post #112

Earlier quoted context omitted.

So stop committing non-workable intermediate stuff and finish what you're doing before committing. I fail to see how it's "a pain" to have a history of everything done. If you want to mark new features or releases, use tags for that.

No, you should never be afraid of committing anything you have at any point in time. Git works as a development tool as well as a central VCS. As long as you have committed something, it will be restorable in case you overwrite it or delete it. Telling someone to wait before committing is a bad idea. They may get a lot of work done and then inadvertently lose it somehow, permanently. Instead, you should commit often…

There's no need to squash commits with rebase. Ever.

Whether you commit often or not does not change the fact that rebase is unnecessary to keep a clean history of features/releases and obscures real commit history.

You can have a clean history of features and/or releases with tags, without destroying commit history.

Re: A simple git branching model

#129

Post by shawnps »

wpietri wrote: post #63
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…

My world really changed once I started working with code bases that had excellent test coverage from the get-go. At my last shop we combined that with pair programming, feature switches, and a few other tricks, and we basically never branched. You'd pull, work for a few hours, push, and 10 minutes later your code would be live. It was in one sense freeing: the release overhead of other shops was gone. And in another,…

That sounds really awesome!

I'm guessing I'll just have to sit down one day and write a whole bunch of tests, and then hope that everyone else will see the benefit.

So you mean everyone just pushed directly to the upstream master?

Re: A simple git branching model

#130

Post by shawnps »

steveklabnik wrote: post #82
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…

You can do this with Travis' new deploy feature.

Oh cool, I've used Travis pretty extensively and didn't know about this feature yet. Thanks!
Post reply on HN