I don't really understand the convenience of merging with Git.I think rebase and cherry pick are convenient.

You are trying to merge conflicting changes, not conflicts when you merge.The merge tool automatically resolves conflicts that should have been manually resolved to some extent.

In reality, even if you say you work with source code in parallel, you usually change another file or even the same file, so git merge automatically handles this.Conflicts that cannot be handled automatically will be solved manually, but it is easy because they mark the points of conflicts.If that sounds difficult, you can wait for the other person to finish the work before making any changes.

That's why I use git merge conveniently.

Cherry-pick, which applies the difference between commit alone and rebase, which tries to merge together, may be easier...Rather, it tends to cause conflicts individually by applying them individually, so I have the impression that merge is more comfortable at the end.

Rather, the merge commit is created for the merge command (which is not a fast-forward merge in ), so it has the advantage of keeping a record of where and when the merge was made.On the other hand, if you don't want to create a merge commit, rebase it, or use cherry-pick if you want to capture only a specific commit.I think this kind of distinction is common.

By the way, I tried the sample.txt example written in the question, but neither merge nor cherry-pick can automatically resolve conflicts.

The example provided is simply considered a line rewrite and conflicts are unlikely to occur.
The following steps are expected.

Conflicts occur when editing to the same location (line) is done at the same time.
If you think that the actual merge takes in additional editing from another branch, it's easy to imagine.

Essentially, the benefit of git's adoption of a merge mechanism is that it can create a commit with two parents.

When you want something like this, it's useful, for example, when you fork an existing repository to make something.

• An existing repository is an existing repository, and its master branch will pile up.
• When you fork, your master is created from the master of the existing repository at that time.
• I will continue to develop at master.Periodically, you can absorb fork source changes by merging origin/master into your master.

Having two parents commit gives them more flexibility in their commit graphs and allows them to manage their code more naturally (compared to having only a straight-line commit history).

Welcome to the world of Git!

The only way to use the merge is to go to the develop branch, create a file called Newsample.txt in the sample directory, and import it into the master.

Let me see your question
One thing I thought was that the questioner misunderstood was
Collision Occurred = Unable to merge.
is not
After a collision occurs, the merge can be completed by eliminating the collision.

Resolve conflicts in merge
http://www.backlog.jp/git-guide/stepup/stepup2_7.html

Even if you make similar modifications to the same file,
You can commit either of them in the merge operation, or you can commit them in a completely different way.

*As the question has been edited, add it

If you want to merge without conflict to the master branch,

Merge without conflict is inevitable for parallel development.
Of course, it is possible for stakeholders to constantly communicate and develop while coordinating to prevent conflicts on Git, but it is only because there is no conflict on Git, but there is a conflict on the project.

I don't think it's a very convenient command. What do you think?

Write a short answer to your question

Conflict is a problem that cannot be solved automatically, so I don't think we need any more functionality as a tool.