Xcode 7.3 As our iOS efforts within our company have expanded, we have multiple teams now and with new members coming and going and multiple versions of multiple products in Git now, I have been surprised to notice that when someone makes a branch and tells me that I can switch to it and evaluate the code, when I select Switch to Branch… the new branches don't show up in the list of branches that I have the option to switch to.
What I have to do is pull my local branch of that project first, then go to Switch to Branch… and then I can see the new branches in the remote origin. Before I say, "this reeks of bad UI design" (though it does since you EXPECT to see all the branches you can switch to when you select Switch to Branch…), is there a compelling reason why this is implemented this way? It's massively unintuitive, you have to have people up to speed in Git knowledge and it's a waste of time since when you select Switch to Branch…, you expect to see the all branches you can switch to if you're connected to the remote. Is there some reason why this was made this way that I need to understand, that I'm plain old missing? Secondarily, I spent yesterday or Monday morning freaking out over a branch merge where I delivered a product to the App Store and then used Xcode to merge the branch it was made from back to trunk. My assumption was that poat a branch merge back to truck, I'd be able to track the commit history to validate that the contents of the branch were indeed merged into the trunk. Now, this is mostly a shortcoming on my side by not understanding how Git works, but the Xcode UI does pretty much nothing to inspire confidence that the entire contents of your branch were successfully merged back in to trunk. Simply put, I was wrong in my assumption of what I would be able to rely on to validate the merge, but Xcode wasn't helping to let me validate the results of the merge. Having to manually inspect files to see see if recent changes were in trunk before I make another branch for us to work on, doesn't exactly inspire confidence. Not being able to see the history of the commits from the branch you merged in is the direct opposite of inspiring confidence that your master and then new branch you're about to make DOES have the results of your last 6 months of work in it. Additionally, some other offshore team merged back to the remote master in February and we suddenly see these unknown commits showing up which lead to even more confusion since we could see these commits in the history, but none of the commits from the branch we had merged into the remote master trunk. So, post merge back to trunk, how does Xcode expect us to verify that the merge went well and all the contents of the merged branch are there? Does it offer any capability for us to do this at all? As a result of this, we spent about an hour or two with two warm bodies learning SourceTree and making sure that the remote master was good after the merge back to it and that the new branch we are going to be working on for the next 6 months provided the correct point to start from. For a company that was once known for setting the standard in usability and intuitive interfaces, you'd expect more information for such a critical pard of any project. This is just about the LAST part of a project where you want your dev tool to skimp on the information it gives you. So, post merge back to trunk, how does Xcode expect us to verify that the merge went well and all the contents of the merged branch are there? Does it offer any capability for us to do this at all? Thanks in advance. Alex Zavatone _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
