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

Visualized Git practices for team: branch, merge, rebase

kentnguyen.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Visualized Git practices for team: branch, merge, rebase

#31

Post by fhwang »

sandGorgon wrote: post #16
fhwang wrote: post #5

Earlier quoted context omitted.

Yeah, personally I know a number of solid devs who like feature toggling but the notion has always rubbed me the wrong way. Especially because half the time I'm adding a non-trivial feature, I'm always semi-refactoring the code underneath to deal with the common patterns and concepts that emerge as a result of that addition. But I'm a big refactoring-as-you-go kind of person--I don't know how common this is. Branchin…

this was a question I had - how do you have your QA,testing,staging setup to test branches ? Or is fast and frequent commits (by design) eliminate the need for the commit-deploy-test cycle and replace it with a review step instead ?

Generally speaking I like to have at least one CI environment available for every branch that makes you nervous, plus master. So what number you're dealing with depends on the team. Sometimes you have eight engineers but only four of them are doing something major at any given time.

Of course, whatever you call what you deploy to production -- master, production, timestamp tagging, etc -- it should ideally pass CI before getting deployed as well. And there are merge conflicts to deal with, too -- that ideally belongs to whoever's doing branching.

So, maybe my ideal workflow looks like this:

  * Branch away from master
  * As you work in your branch, grab a CI server if you feel like it (telling
    everyone else)
  * Commit code in your branch, keeping an eye on your CI as you go
  * Periodically merge in from master, dealing with merge conflicts in your branch,
    *not* in master
  * When you feel like it's ready to go, get whatever review you feel like you
    need -- code review, product manager review, etc
  * If you feel 99% certain it's good, merge it into master and push that back to
    origin
  * Wait for master CI to pass
  * Deploy to production
  * Beer
From an etiquette point of view, there are things that can go wrong, not least the individual commitment to deal with merge conflicts before they get involved in master. And conflict resolution cannot be rushed. If you have engineers who are just gonna edit files randomly to get git to accept their merge, you're going to have problems. (But if you have those sorts of engineers, you already have problems.)

Re: Visualized Git practices for team: branch, merge, rebase

#32

Post by Davertron »

wanderr wrote: post #26
Davertron wrote: post #12

Earlier quoted context omitted.

My understanding is that it keeps the history cleaner at the expense of being "historically correct". It's cleaner because you have fewer merge commits, but less historically correct because it makes your commits look like they happened after the commits pulled in by rebase. Personally, I use merge (with --no-ff) vs. rebase. The only time I actually use rebase is to squash a series of (unpushed!) commits on a feature…

It keeps the upstream history cleaner at the expense of being locally historically correct. In my opinion the nice thing about having everyone rebase onto upstream is that when their changes get merged into upstream, upstream's history shows an accurate linear representation of when a piece of code was accepted into upstream, which to me is far more important than having an accurate local history.

Great point. One of the more confusing things about looking at the upstream logs when not using rebase is that they are (by default) in chronological order. It does seem like it would be more useful to have commits upstream show in the order they were merged in.

Re: Visualized Git practices for team: branch, merge, rebase

#33

Post by nazri1 »

The merge-often strategy that the OP recommend in his post is the one that is Linus abhors so much. He even calls it "unholy mess" : https://lkml.org/lkml/2012/1/10/267. Basically that merge strategy can produce pointless merges.

See this discussion: http://git.661346.n2.nabble.com/Re-Regulator-updates-for-3-3... on the git developer mailing list for more details on why that merging strategy is not liked.

Re: Visualized Git practices for team: branch, merge, rebase

#34

Post by lnguyen »

nazri1 wrote: post #33

The merge-often strategy that the OP recommend in his post is the one that is Linus abhors so much. He even calls it "unholy mess" : https://lkml.org/lkml/2012/1/10/267 . Basically that merge strategy can produce pointless merges. See this discussion: http://git.661346.n2.nabble.com/Re-Regulator-updates-for-3-3... on the git developer mailing list for more details on why that merging strategy is not liked.

The strategy isn't the issue. It's whether it fits with the process you've set up.

If you do code-review on the contributions/pull requests then I can see where the merge-often strategy causes issues. The auto-generated merge commits don't give you the context of the updates that are pulled in and will lead to having to spend time going back through the commit tree. It may not lead to the introduction of issues or regressions but you can't be sure.

However, if you're set up as a small team with good internal communication or a high level of trust, then merge-often can be a good thing in that you usually aren't left with big merge issues to deal with and you're more likely to have any conflicting updates fresh in your mind.

Re: Visualized Git practices for team: branch, merge, rebase

#35

Post by lnguyen »

gavingmiller wrote: post #8

The OP gives his own definition for rebase: git rebasing is taking all your local changes since the last push and put them ahead of other people’s changes regardless of the date you made the commit. But fails to explain _why_ you'd want to do that. Can anyone fill in that why for me?

Something I wrote up nearly three years ago that should explain rebase vs merge

http://gitguru.com/2009/02/03/rebase-v-merge-in-git/

I really should go back and start making new blog posts... I'd dropped the ball because I ended up on a few enterprise SCM (software configuration management) gigs shortly after.

Re: Visualized Git practices for team: branch, merge, rebase

#36

Post by lucisferre »

His opinions on not rebasing onto master and instead merging are his own. Personally I find merging far more confusing in terms of understanding history graphs and always rebase before issuing a pull request. I think you will find that generally a lot of open source projects on Github have this practice of asking people to "please rebase your changes onto master so I can merge".

One practical reason is when doing bisects.

There are certainly two schools of thought on this, but "this is confusing to me so don't do it" shouldn't be considered a valid opinion.

Re: Visualized Git practices for team: branch, merge, rebase

#37

Post by lucisferre »

lnguyen wrote: post #34
nazri1 wrote: post #33

The merge-often strategy that the OP recommend in his post is the one that is Linus abhors so much. He even calls it "unholy mess" : https://lkml.org/lkml/2012/1/10/267 . Basically that merge strategy can produce pointless merges. See this discussion: http://git.661346.n2.nabble.com/Re-Regulator-updates-for-3-3... on the git developer mailing list for more details on why that merging strategy is not liked.

The strategy isn't the issue. It's whether it fits with the process you've set up. If you do code-review on the contributions/pull requests then I can see where the merge-often strategy causes issues. The auto-generated merge commits don't give you the context of the updates that are pulled in and will lead to having to spend time going back through the commit tree. It may not lead to the introduction of issues or re…

We solve the problem with rebasing. If it's not part of the main branch then it's not part of history, so rebasing to organize the pull request makes sense.

Re: Visualized Git practices for team: branch, merge, rebase

#38

Post by lnguyen »

lucisferre wrote: post #37
lnguyen wrote: post #34

Earlier quoted context omitted.

The strategy isn't the issue. It's whether it fits with the process you've set up. If you do code-review on the contributions/pull requests then I can see where the merge-often strategy causes issues. The auto-generated merge commits don't give you the context of the updates that are pulled in and will lead to having to spend time going back through the commit tree. It may not lead to the introduction of issues or re…

We solve the problem with rebasing. If it's not part of the main branch then it's not part of history, so rebasing to organize the pull request makes sense.

Rebase works great when you need/want to preserve he revision history. It's probably the ideal process to put in place if you can mandate it.

One thing to keep in mind is that it might lead to a number of merge conflicts that may be difficult or tedious to resolve depending of how the branches have diverged. Merging may avoid these.

Re: Visualized Git practices for team: branch, merge, rebase

#39

Post by lucisferre »

lnguyen wrote: post #38
lucisferre wrote: post #37

Earlier quoted context omitted.

We solve the problem with rebasing. If it's not part of the main branch then it's not part of history, so rebasing to organize the pull request makes sense.

Rebase works great when you need/want to preserve he revision history. It's probably the ideal process to put in place if you can mandate it. One thing to keep in mind is that it might lead to a number of merge conflicts that may be difficult or tedious to resolve depending of how the branches have diverged. Merging may avoid these.

Why would regular merging avoid this more than regular rebasing? The result is the same.
Post reply on HN