GitHub Community
Would you rather Rebase or Merge? #21558
-
|
which one is better in a production environment? I’m not too familiar with rebasing, but it seems like in the production environment it isn’t very safe. I’m used to merging, and wondering if there is any benefit to rebase rather than merge or what are the specific use cases. Let me know your opinions or thoughts! |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments
-
|
I prefer to using Rebase still the Merge operation will preserved every log you have commited.The Rebase operation will cause a clean log history which is the reason I choose for.
|
Beta Was this translation helpful? Give feedback.
-
|
I’ve always used this as a rule of thumb, if you are working with others on the same branch, never rebase. Otherwise you can go ahead and rebase to your hearts content. Rebase moves all of the commits from let’s say master to the tip of your feature branch. Keep in mind that this only happenes in_ _repository. All of the other developers, you’re working with, are still working with the original master. Rebasing results in brand new commits, and Git will think that your branch’s history has diverged from everybody else’s. So to answer your question: it depends on the case. |
Beta Was this translation helpful? Give feedback.
-
|
i only ever merge never rebase |
Beta Was this translation helpful? Give feedback.
-
|
Why do you never rebase? |
Beta Was this translation helpful? Give feedback.
-
|
My colleagues and I always use pull requests and merge them. The PR process allows us to do code reviews in a non-threatening way. A few years ago when we used live, in-person code reviews, some developers were too sensitive to take constructive criticism of their code. (And some were too afraid to give criticism.) Before my group began using GitHub for almost everything, we used Review Board for our reviews, which was very good. It made reviews very non-confrontational. I didn’t have a problem with in-person reviews, but I found online reviews with RB to make the process a lot smoother. I still miss some of RB’s features that GH code reviews don’t support. We continued to use RB for a little while after we began using GH, because GH’s review UI wasn’t as good then as it is today. Getting back to merge vs. rebase: GH’s PR features now have a “squash and merge” option. A PR containing multiple commits can be squashed down to a single commit just before it’s merged. I think that would address the problem mentioned by @suvinseptue. Besides the code review feature, honestly, I think using PRs and merging them is a little easier process for people to understand, especially if they’re new to git. It also goes along with the methodology we’ve adapted to our work. (Only work from a personal fork, not the original (“upstream”) repo. Each issue being addressed is implemented in a dedicated branch of our forks. Pull requests of completed work are made from our fork branches back to the upstream repo.) |
Beta Was this translation helpful? Give feedback.
I’ve always used this as a rule of thumb, if you are working with others on the same branch, never rebase. Otherwise you can go ahead and rebase to your hearts content.
Rebase moves all of the commits from let’s say master to the tip of your feature branch. Keep in mind that this only happenes in_ _repository. All of the other developers, you’re working with, are still working with the original master. Rebasing results in brand new commits, and Git will think that your branch’s history has diverged from everybody else’s.
So to answer your question: it depends on the case.