-5

This may seem like a stupid question, but I really think git might make my life easier if it does not has such a feature. My proposed solution for a git without merge or my comparison target is here:

People using git without merge will always use some show-difference tool to display the differences between source branch and their current (perhaps master) and get the changes one by one into their branch.

My reason goes as below:

  1. git merge will not naturally delete originally branch, DRAW (because my proposed method does not as well)
  2. git merge causes confusing commit graph, while only indicating that the source branch provided some contribution to the original branch, LOSE (because my method would not show a confluence in the git commit graph, and we can actually tell others where this commit has its contribution from manually)
  3. When there are a lit of conflicts, DRAW (git merge is causing many troubles, as smart merge would have to be invented; while my method would simply not be more troublesome than git merge)

Any comments would help!

Ke Li
  • 391
  • 3
  • 5
  • It would be worth mentioning what you're comparing git merge *with*. SVN? Git rebase? Or what. What changes do you even need to incorporate from different branches? – VLAZ Apr 26 '20 at 14:24
  • See [Why is a 3-way merge advantageous over a 2-way merge?](https://stackoverflow.com/q/4129049/1256452) – torek Apr 26 '20 at 19:32
  • What *is* your proposed solution? Your edit just adds words indicating you have one but I do not see what it is. – VLAZ Apr 27 '20 at 05:21

2 Answers2

2

well git merge is a powerful and essential tool which is part of any version control software. How you use it is entirely up to you.

  1. True, the branch will not automatically be deleted, but that is intentional and is not supposed to do it automatically since remember what a version control software is supposed to do, is to track/log changes and versions during the development of software. Even when deleting the branch or reverting you are not deleting per say, you are just deleting a pointer to the commit. Imagine if a feature branch X is deleted altogether and then you have a merge to master with commit message "merge branch X into master", if someone new comes in and looks at the history they will wonder where the X branch, it just a recipe for confusion and headaches.

  2. I wouldn't consider this a drawback at all, most of the time you want to know which branch was merged to master at which point, helps tracking bugs and identify what branch has introduced it. If you mean that the graph can become confusing due to the amount of lines you have other ways of managing that using techniques like git rebase to have one neat line. I don't get what you mean to merge one by one, first you should merge as often as possible and if you have some automated testing you can quickly see if what you push passes your tests or not. If you want to really merge one by one then you can always use cherry picking, git provides almost everything and anything.

  3. Conflicts, well unless you have multiple people working on the same part of the project you should not come across this issue. However, if you do get into trouble you have many software tools to resolve conflicts and then merge them back into the branch, but as I said before it should not happen unless 2 or more people are modifying the same part

Alex Goja
  • 548
  • 5
  • 18
2

I'm having trouble understanding your "problem".

If merge isn't useful for you, how do you add a modification set to your main branch?

If I understand correctly, you would only use rebases in order to keep only one development branch.

Each merge ends with a merge commit that resolves conflicts and keeps the feature branch intact.

The rebase cannot be reverted simply to a commit and will keep less track of the features. Moreover, if conflicts exists, you have to modify your feature branch.

I usually work using git-flow approach with my team, so it allow for reviews and CI before mergin a feature branch. Also, i frequently rebase my feature branch on develop to get last version of some APIs and keep a clean git tree instead of mergin develop in my feature branch.

In conclusion, I think merge doesn't have to be systematic but is essential for versioning. For all my local changes, i always work with VSCode and gitGraph plugin which increase readability and my productivity (for your remark 1 and 2). For all automation or push, i use command line. I don't know if I answered your question.

Lefix
  • 55
  • 7