8

I was just about to start a git branch off the master branch to add some functionality to my application, that would also involve some additions to the interface.

However, i already have a branch for some other functionality that also involves some interface additions.

Will i be able to merge both those branches to master when i finish with them? Is there some good practice to, probably, structure xib-files in a certain way that would make it easy to merge afterwards?

Josh Lee
  • 171,072
  • 38
  • 269
  • 275
Ibolit
  • 9,218
  • 7
  • 52
  • 96

2 Answers2

6

What if I, for example, have a tab view with three tabs in one branch, and a tab view with three tabs in the other, and two of the tabs are the same, and one is not, will i get a four-tabbed tab view after the merge

You will most likely have a conflict, if the modified lines (involved in the tab definitions) are the same.
You will have 4 tabs only if, during the manual merge resolution, you mistakingly leave an extra tab definition.

See Painless Merge Conflict Resolution in Git for a great article on merge resolution.

3-way merge

That being said, regarding xibs specifically, its presentation seems good:

As of Interface Builder version 3, a new file format (with extension .xib) has been added, which is functionally identical to .nib, except it is stored in a flat file, making it more suitable for storage in revision control systems and processing by tools such as diff.

But this thread summarizes the actual feeling:

How is Git able to merge changes to XIBs?
The structure of an XIB isn't linear; there's no guarantee that you can just swap out portions of an XIB and wind up with a usable XIB.
Unless Git has an understanding of XIBs near Apple's, I don't see how merging could be guaranteed to work.

That would leave you with the extra step, before adding your merge resolution in case of conflict, to open the modified .xib file in your XCode4 editor and check if everything still looks good.

XCode4 xib file Editor

Once that visual check is done, record the merge resolution through rerere, and you will have potentially automatic resolution in the future.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you. Yes, i know about conflict resolution in git, and this question is not so much about git as such, but about *xibs* in git (xibs are interfaces for Mac OS X applications, created in a visual editor Interface Builder, they are almost impossible to read). – Ibolit Mar 25 '11 at 18:43
  • @Ibolit: I understand. That seems to leave you only with the extra step of visual check, before recording the merge resolution result with `git rerere`. More in my updated answer. – VonC Mar 25 '11 at 19:36
  • the above [article](http://blog.wuwon.id.au/2010/09/painless-merge-conflict-resolution-in.html) talks about using meld.. a non osx compatible diff merge tool.. is there any mac replacement you recommend in its place? – abbood Nov 14 '12 at 06:00
  • @abbood I don't have direct experience with Mac, but http://stackoverflow.com/questions/187064/graphical-diff-for-mac-os-x could help (combined with http://www.jotlab.com/2009/11/16/how-to-use-filemerge-with-git-as-a-diff-tool-on-osx/). Or http://stackoverflow.com/questions/736911/how-do-you-make-git-diff-use-gitx-diff-on-os-x – VonC Nov 14 '12 at 06:14
  • thanks Von, and just for reference I've decided to use diffmerge (rather than filemerge, which comes pre-installed with xcode).. I find it a lot more powerful (for example.. it does same line comparison, something that filemerge don't).. that said, here is a link to my [.gitconfig](https://github.com/abbood/gitConfig) file that can be useful for xcode users wanting to use git for the first time.. – abbood Nov 14 '12 at 07:02
0

Of course you will be able to merge them both into master. It doesn't matter how you structure your files, git doesn't care about that.

rtn
  • 127,556
  • 20
  • 111
  • 121
  • 3
    This is an oversimplification: the OP is asking about two branches which make modifications to the same thing, the interface. They could potentially cause merge conflicts. Resolvable ones, yes, but something to be aware of. – Cascabel Mar 25 '11 at 17:02
  • 4
    The thing is that when i resolve conflicts in other files, i understand what i am doing, i know what particular lines mean. In this case i will see just some xml that will not mean anything to me. If i make a mistake while merging, there is little chance i will be able to find an correct that mistake. Again, what if i, for example, have a tab view with three tabs in one branch, and a tab view with three tabs in the other, and two of the tabs are the same, and one is not, will i get a four-tabbed tab view after the merge? – Ibolit Mar 25 '11 at 17:20