On Apr 25, 2017, at 8:42 PM, Alex Zavatone <
email@hidden> wrote:
We had one team member making changes over and over, and she only made them to her local build scheme because she was using SourceTree.
Those schemes should have been marked as shared, then. Even Xcode won’t commit them to the repo if they’re not shared.
Also, we ran into dependency hell because of the xcblueprint being completely skipped when using SourceTree.
The xcblueprint will show up in SourceTree with a “?” icon as a file not under version control. At that point you can decide whether to commit it or add it to the ignore list. Sounds like someone made the wrong decision to mark it as ignored.
It’s also worth noting that the xcblueprint file is only needed for Xcode’s own Git support, which is very, um, idiosyncratic. In projects I work on, we ignore xcblueprints and just never use Xcode to commit or check out. (Xcode doesn’t understand submodules anyway, and will really screw up checkouts of projects that use them.)
Today, I had 2 merge conflicts with pretty useless files. Tried to resolve using SourceTree. Project was left unopenable.
Conflicts in the .pbxproj file can be a bitch, but I don’t think Xcode does any better at auto-merging them than SourceTree does; at some point you have to go into the individual diffs and decide what to merge.
Couldn't cancel the merge, couldn't reverse any commits.
I don’t know how that could happen, unless you ran into a serious bug in SourceTree. You can always cancel a merge or reverse commits in Git.
I think Xcode is probably acceptable for very simple repositories that are (a) only used with Xcode, and (b) don’t have fancy stuff like submodules. If it gets more developers to start using version control, that’s awesome.
SourceTree is very acceptable to me and lots of other people.