# Reducing the pain of git bisect with Xcode

DevFeed: [Reducing the pain of git bisect with Xcode](<https://devfeed.tech/articles/reducing-the-pain-of-git-bisect-with-xcode-21618.md>)

Original publisher: [Read original article](<http://miqu.me/blog/2017/01/22/reducing-the-pain-of-git-bisect-with-xcode/>)

Author: Miguel Angel Quiñones

Published: 2017-01-22T11:49:01Z

Content type: tutorial

Language: en

Sources: [Miguel Quinones](<https://devfeed.tech/sources/miguel-quinones.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Xcode](<https://devfeed.tech/topics/xcode.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [debugging](<https://devfeed.tech/topics/debugging.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [git](<https://devfeed.tech/tags/git.md>), [ios](<https://devfeed.tech/tags/ios.md>), [ios-development](<https://devfeed.tech/tags/ios-development.md>), [xcode](<https://devfeed.tech/tags/xcode.md>)

## AI overview

This article explains how Git bisect can identify regressions by performing a binary search through repository history. It focuses on reducing the friction of using bisect in iOS projects with CocoaPods and Xcode, including dependency installation, manual reproduction, device testing, app reinstallation, and repeated Xcode indexing. It begins describing automation that closes Xcode, updates dependencies, and reopens Xcode after each bisect step.

## Source excerpt

There's times when you need to investigate regressions in your project, and you don't know have any clue as why something is happening. Git bisect is the best tool for this cases, but it can be painful to use in non small projects using CocoaPods and Xcode. I want to share what I've been doing to ease the pain. If you never used Git bisect, check this introduction. The git command performs a binary search across your repository history, starting from two known commits you provide to the algorithm: 'Good' and 'Bad'. 'Bad' will usually be your last commit, and 'Good' will be a commit back in the history of your repository, when you know the code was working as expected. For every step of the search you need to tell git if a commit is good or bad, either manually or automatically by running a script. Pain points When we enter the realm of iOS development, there's a some factors that make bisect tedious to use. If you use CocoaPods, and if you don't check in the 'Pods' directory in source control, every time you change branch or bisect selects a new commit, you might need to run pod install in order to have all dependencies available and compile correctly. If you are searching for a regression, chances are you don't have an automated test suite, so you'll need to run your app manually and reproduce the issue you are searching for. There will be cases when you're dealing with a bug that needs an app reinstall or needs to run on device to reproduce. To top all this, Xcode will start the long indexing process every time there's changes to the sources due to change of commit, so your computer will start doing lot of work. All of these nuances makes the process of searching for issues using bisect very tedious and not so 'magical' as it is supposed to be. I've nevertheless used bisect many times to save time otherwise wasted reading code and navigating breakpoints during long debugging sessions. You just need some patience and the will to automate some stuff. Reducing the pa