Hacker News new | past | comments | ask | show | jobs | submit login

I had a lot of success with a master branch, all features built in feature branches.

Feature branches were rebased then merged with a --no-ff. This creates a merge commit on master which includes the ticket number and short description.

The rebase is done by the feature branch developer who is usually best qualified to do so.

The advantage is that changes are isolated from each other, so nothing is spread before it's reviewed. The rebase makes the history easy to follow because it becomes linear and you can always easily see exactly what was changed in the branch. You still retain the full history of the feature branches.

Disadvantages: it doesn't scale to a massive team because you need to linearize the merges back to master. So it works for upto around 20 people.

I'd recommend against Git Flow because their method of merging makes it very unclear exactly what was changed in a branch. I actually prefer no feature branches to using Git Flow.




I should add: the feature branches are short lived for normal feature development. As in 50% last a day, 80% two days and 95% a week.

As the above post mentions I like to use feature flags to make this possible.


I would strongly recommend avoiding a rebase-based strategy. When developers at my company run into git issues, they are almost always the result of a bad or confusing rebase.

My team's process is simple and easy for anyone to follow: all feature work is done on feature branches. Branches should be kept small and atomic. When they've passed code review, squash and merge into Master.

If you need to pull changes from master, always merge into your feature branch, never rebase.


It sounds like you've had people rebasing some public commit which has then been branched from. That's asking for trouble.

Rebasing is wonderful, it makes Git a joy to use. But you have to understand the process and, most importantly, train your team so that they also understand it.

As I've said, I've had great experiences working like this; but it took a lot of effort and support of my senior developers to get the team up to speed.


I would disagree with the strongly recommend here, because rebasing makes it so much easier to track down bugs and isolate breaking changes.

Of course, this does require someone to be more proficient with Git beyond the simple add, commit, fetch, push model, which has its own drawbacks.

Also, at least in Git, squash is just one use case of interactive rebase, so I'm not quite sure what you're arguing against...


Can you go more in depth with this process on how rebasing things makes it easier to track down bugs / breaking changes? Usually you can track down which feature branch is the one that cause a regression in your code base, and you can also look at specific commits to find out where problems happen. I can't tell how a rebasing flow would make this any easier?


How do you squash commits without rebasing?


    git checkout master
    git merge --squash some-feature-branch




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: