Need a Git branching how-to

Question

Using GitFlow, I created a new class on the develop branch and gave it a property:

Public Class Class1
 Public Property Property1 As String
End Class

I committed that change and created a new feature named feature2. In that branch I added a property:

Public Class Class1
 Public Property Property1 As String
 Public Property Property2 As String
End Class

I committed that change and checked out develop. I then created another new feature named feature3. In that branch I added a property:

Public Class Class1
 Public Property Property1 As String
 Public Property Property3 As String
End Class

I committed that change and checked out feature2. I finished that feature, which merged it back into develop. I now had this in develop:

Public Class Class1
 Public Property Property1 As String
 Public Property Property2 As String
End Class

All was well so far.

But when I checked out the remaining feature3 and attempted to finish it, I got a merge conflict in develop. The IDE wanted me to choose between the class with Property2 and the class with Property3. This won't work for my test scenario, as I need all three properties.

I did all this so I could learn a little bit about how Git branching works, in preparation for a bug fix I'm about to start. The bug report came in just now, and unfortunately it's in production. So I have to fix it immediately; the feature branch I've been working on over the past week is going to have to wait.

But if I create a new branch for the bug fix I'll end up with merge conflicts, as the code involved in the fix will greatly affect the code in the feature branch.

Is the answer to this dilemma to merge bug-fix into develop, and then develop into new-feature once I'm finished with the fix and it's pushed into production?

If so, this model could get really complicated really fast. Let's say I have several feature branches in various stages of development: how am I to track which branch has been merged with which, and when? (Note: I'm a solo dev.)

--EDIT--

I tried this just now—merging develop back into feature3—and I'm getting a similar conflict. Git seems to be operating at the file level, not the line-of-code level. So no go with that idea.

How is all of this branching/merging supposed to work, when multiple branches are at play?

--EDIT--

Here's a sample image of a GitFlow branching model (below). See how hotfix is derived from master, and then merged into develop? That's all well and good, I suppose, until feature is merged into develop right after that. We're going to get conflicts during that second merge!

What to do when hotfix contains major architectural changes that deeply affect everything going forward? Merging will be all but impossible at that point.

What am I missing here?

---

GitFlow sample

• Stack Exchange Broke The Law: You... fix the merge conflict by including both of the new properties?

Answer 1

Here's a sample image of a GitFlow branching model (below). See how hotfix is derived from master, and then merged into develop? That's all well and good, I suppose, until feature is merged into develop right after that. We're going to get conflicts during that second merge!

What to do when hotfix contains major architectural changes that deeply affect everything going forward? Merging will be all but impossible at that point.

What am I missing here?

When you branch for the hotfix, merge hotfix -> develop, then you should refresh your feature branches from develop so they have the latest changes.

It sounds like you have it, just don't be afraid of merge conflicts. They will happen when you have multiple people working on a project, but if you keep your feature branch relatively refreshed (merge from develop to get others' changes often) git should be able to work out the majority of them.

If you have a hotfix with large architectural changes, that seems like a horrible "hotfix". However, same principle applies.

• InteXX: Got it, thanks. I think I was getting hung up on how to do a merge conflict. I just found out that the VS2017 IDE provides an easy way to do this, at the line-of-code level. I don't have to take an all-or-nothing approach. For some reason, I was overlooking the Merge button on the Merge Conflict tab in VS. This button takes us to a line-by-line conflict resolution UI. Is this UI what you're talking about when you refer to resolving merge conflicts?
• Mike: There are various tools, VS has one, GitExtensions uses kdiff3, you'll have to play around and see what you like, tons of options. But yes, the merge tool should take you through line for line the areas that git can't automagically figure out what to do, then you just have to make a decision.

Answer 2

You fix the merge conflict. A merge conflict doesn't mean you can't merge, it means you can't automatically merge.

To reiterate, your IDE is asking you how to combine

Public Class Class1
 Public Property Property1 As String
 Public Property Property2 As String <- new line
End Class

with

Public Class Class1
 Public Property Property1 As String
 Public Property Property3 As String <- new line
End Class

In plain Git, if you did the merge (git merge feature3 with the develop branch already selected) it would show you something like this:

Public Class Class1
 Public Property Property1 As String
<<<<<<< HEAD
 Public Property Property2 As String
=======
 Public Property Property3 As String
>>>>>>> feature3
End Class

The parts between the <<<<<<<>>>>>>> markers are the two sections of code that you need to merge. In this case, you want to use both lines of code, so you simply delete the markers and end up with this:

Public Class Class1
 Public Property Property1 As String
 Public Property Property2 As String
 Public Property Property3 As String
End Class

and then finish the merge (git add and git commit on the command line).

I'm not familiar with merging in Visual Studio, but it should have a similar way for you to resolve the conflict.

• InteXX: This is good stuff, thank you. I'm torn... I can't decide whose answer is best—yours or Mike's :-)