0

it may sound a stupid question but I was working only in master branch and I had a .txt file like this:

abc
def

then I changed it to 

abc
ghi

then I did

$ git add .
$ git commit -m "trying to cause conflict"
$ git push

And it worked without any problems, the file was changed. I wondered if git cares about this case of "conflict" if the project doesn't have branches except for master.

Jon Kiparsky
  • 7,499
  • 2
  • 23
  • 38
  • 2
    A conflict occurs because a commit has two parents, each of which has a different version of one or more files. In your example, the branch only has a single line, hence there can be no conflicts. Git can completely figure out how to get from the first version to the second one. – Tim Biegeleisen May 15 '17 at 05:44
  • so a conflict will only occur if the situation of the .txt file I mentioned happens, but a version coming from a branch and other version coming from another? –  May 15 '17 at 05:47
  • 2
    Yes, but even that is not guaranteed to cause a conflict. Git _may_ be able to resolve the changes without any conflict at all. Or, there could be a merge conflict. Ideally, if your team plans its Git workflow well, there should be very few merge conflicts if any day-to-day. – Tim Biegeleisen May 15 '17 at 05:49
  • Planning can be important - if two people work on the same file, you might easily find yourself making changes which conflict in ways which git cannot detect. For example, if one commit removes the definition of some function f and a simultaneous commit adds a call to that function, git will accept these as compatible but of course the code will fail. This is one of the many reasons for having solid tests, and using them. – Jon Kiparsky May 15 '17 at 05:54

3 Answers3

1

The answer depends on how you define "branch".

In Git, the word "branch" can mean either a branch name like master, or a branch within the commit graph. (See also What exactly do we mean by "branch"?)

Normally, to get a branch within the commit graph, you need at least two names. However, branches like master are shorthand for names that begin with the literal text refs/heads/: the branch master is really refs/heads/master, and if you create a branch named A it has the full name refs/heads/A. Your Git stores these names in its own private table of name-to-hash-ID mappings. This table also has tag names, like v2.3, which are short for names within refs/tags/, and what Git calls remote-tracking branches like origin/master, which are short for refs/remotes/origin/master.

If you have an origin, you probably have an origin/master to go along with your own master. This gives you two names. Only one is a branch name, but both may—depending on how you define "branch"—result in branches!

Besides all this, you can create anonymous branches (if you choose to call them branches in the first place) using a "detached HEAD". You can then name commits by their raw hash IDs, and by merging such commits, create a merge conflict. This is a way to get a conflict with only one branch name. But are there multiple branches? Again, that's up to whoever defines "branch".

Community
  • 1
  • 1
torek
  • 448,244
  • 59
  • 642
  • 775
0

The canonical way to get a merge conflict is to start on branch alpha and create branch beta off of alpha, and then make incompatible changes on both branches. In your example, you are simply changing the contents of the text file, and git will happily track that change (and revert it, stash it, use it for a cherry-pick, or whatever else you might want to do).

Jon Kiparsky
  • 7,499
  • 2
  • 23
  • 38
0

When you don't have any other explicit branches and you are the only one, it's still possible to have conflicts.

It can happen when the current head is diverged with the master. Technically the current head, detached or still named as master, is another branch different from the original master. Sometimes it just comes when you don't maintain the local master well. When you run 'git pull', the conflicts can happen if the current head and the remote master have different contents at the same chunk.

Another possible case is when you try to re-apply an old commit or patch. You make Commit A, and then revert it via git revert A to make Commit B. Later you make a new commit C which touches parts or all of the same chunks of A with different changes. Now if you cherry-pick A, conflicts come about.

When conflicts happen, have a check if the workflow is reasonable and then just resolve them.

ElpieKay
  • 27,194
  • 6
  • 32
  • 53