[Swift] XCode Project File (.xcodeproj, .pbxproj) & Conflict에 대하여

 

 

Xcode Project

An Xcode project is a repository for all the files, resources, and information required to build one or more software products. A project contains all the elements used to build your products and maintains the relationships between those elements. It contains one or more targets, which specify how to build products.
A project defines default build settings for all the targets in the project (each target can also specify its own build settings, which override the project build settings).

 

 

 

An Xcode project file contains the following information:

• References to source files:
  • Source code, including header files and implementation files
  • Libraries and frameworks, internal and external
  • Resource files
  • Image files
  • Interface Builder (nib) files
• Groups used to organize the source files in the structure navigator (계층으로 보이는 폴더들(그룹)도 포함된다)
• Project-level build configurations. You can specify more than one build configuration for a project;
  for example, you might have debug and release build settings for a project. 
• Targets, where each target specifies:
  • A reference to one product built by the project
  • References to the source files needed to build that product
  • The build configurations that can be used to build that product, including dependencies on other targets and other settings; the project-level build settings are used when the targets’ build configurations do not override them 
• The executable environments(실행 환경) that can be used to debug or test the program, where each executable environment specifies:
  • What executable to launch when you run or debug from Xcode
  • Command-line arguments to be passed to the executable, if any
  • Environmental variables to be set when the program runs, if any

A project can stand alone or can be included in a workspace.

You use Xcode schemes to specify which target, build configuration, and executable configuration is active at a given time.

 

 

 

• Project는 Application을 빌드하기 위한 파일, 리소스, 정보를 담은 repository
• 처음 Xcode를 켜고 Single View Application을 생성하면 Project를 생성하게 됩니다. 이때, 프로젝트의 디렉토리를 살펴보게 되면 프로젝트명.xcodeproj라는 파일이 생긴 것을 확인할 수 있습니다.
• 정확히 얘기하면 이는 파일이 아니라 디렉토리입니다.
  터미널을 통해 해당 파일로 들어가게 되면 project.pbxproj이라는 파일과 xcuserdata라는 디렉토리가 존재합니다.

 

• project.pbxproj가 실제 설정 파일이다. 
• 프로젝트 내부에서 생성된 파일을, 파일 유형에 따라 reference를 저장하는 역할
• .xcodeproj : 파일이 아닌 디렉토리임을 주의!
   해당 디렉토리에 project.pbxproj 파일, project.xcworkspace 파일,  xcuserdata 디렉토리가 존재

 

• 이 project.pbxproj는 사실 git을 사용할 경우 충돌이 일어나는 주요 파일 중 하나!
• xcode의 최상위 프로젝트 관리 패키지인 .pbxproj의 경우 git 병합시 어떻게 병합할 것인가에 대해 난감한 경우가 많음
• 2명의 팀원이 작업을 위해 각자 A 파일, B 파일을 생성하여 각자 커밋한 경우 한 쪽에는 B 파일의 reference, 다른 쪽은 A 파일의 reference가 없습니다. 그래서 두 작업에서 사용된 project.pbxproj 파일은 서로 다른 reference를 가지고 있어서 conflict가 일어납니다.
  그리고 이 충돌이 고치기 쉽지 않은 것이 project.pbxproj가 깨지면 프로젝트 자체가 열리지 않습니다. 그러므로 이럴 때는 에디터나 소스트리 같은 형상 관리 툴로 해당 충돌을 수정해야 합니다. (dev - dev - mybranch)
• xcuserdata는 프로젝트의 개인 설정을 담은 디렉토리: breakpoint, UI layout 설정 등을 담아, 프로젝트 자체에 크게 영향을 주지 않는 디렉토리 (.xcuserdata 추적 방지 추가 설정 가능)

 

• Workspace는 여러 개의 Project를 담아 관리할 수 있도록 해주는 개념
• CocoaPod 사용 시 접하게 된 경우 많다. (나도!)

 

• Target은 프로젝트를 통해 생성되는 Application을 지칭함. 일반적으로 하나의 모듈을 의미
• Target은 Xcode의 빌드를 통해 생성된 최종 product
• Target은 어떻게 프로젝트를 빌드할 것인지를 담당
• 기본적으로 Target은 프로젝트 생성시 1개만 생성되지만, 목적에 따라서 하나의 프로젝트에 여러 개의 Target을 생성할 수 있음
  • 각각의 target은 프로젝트의 build setting을 설정할 수 있다.
  • 각각의 target은 프로젝트에서 포함될 객체, 리소스, 혹은 별도의 스크립트를 따로 설정하도록 함
  • Xcode에서는 target을 통해서 하나의 프로젝트를 여러 개의 배포판으로 사용할 수 있도록 함
    (i.e. iPhone용 target, iPad용 target, 특정 라이브러리가 포함된 target 등)

 

• Scheme은 Target이 프로젝트를 Build, Profile, Test등을 할 때 일어날 일들을 정의할 수 있도록 해주는 항목
• Scheme에서는 프로젝트 빌드시 사용되는 환경변수나 인자를 넘겨줄 수 있음
• Scheme은 프로젝트의 런타임에서 일어날 일을 설정할 수 있음

 

 

 

• pbxproj is an important file in the Xcode configuration bundle. It is responsible for maintaining references to all of the linked files and their groupings, linked frameworks, and most importantly, the project's build settings
• pbxproj 파일은 Build Setting(실제 프로젝트의 설정) 을 담은 파일
  프로젝트 내부에서 생성된 파일들을 파일 유형에 따라 reference를 저장하고 있음
  conflict는 파일에 대한 reference가 없을 때 일어난다.
• 중요한 파일이므로 .gitignore에 추가할 수 없는 파일이다. 
• pbxproj 파일은 보기가 너무 불편하다. Pro Git Book 에서는 사실 텍스트 파일이지만 만든 목적과 의도를 보면 바이너리 파일이라고 말하며, 여러 명이 이 파일을 동시에 수정하고 Merge 할 때 diff가 도움이 되지 않고 프로그램이 읽고 쓰는 파일이기 때문에 바이너리 파일처럼 취급하는 것이 옳다고 한다. (나는 이 파일로 conflict 해결을 직접 했었는데.. 다른 방도로는 pbxproj 파일을 binary 파일로 취급하기 위해 프로젝트 최상위 폴더(README.md가 있는 곳)에서 .gitattributes 파일을 만들어, conflict 발생을 해결할 수 있다고 한다.)

 

 

 

• 이번 프로젝트에서 파일 오류가 발생한 이유 (빨간 글씨 뜨는 오류 -> 종종 발생한다)
  • 추가된 파일에 대하여 project file을 통한 reference가 제대로 따라오지 않아서
  • 로컬에는 제대로 들어가 있는 파일들을, 직접 재연결해주면 해결된다
  • + build Phase에서 .gitkeep 지우기
• 파일에 대한 참조는 xcodeproj/project.pbxproj 파일에 저장하고 있다. 
  따라서, 파일을 추가하거나 삭제한 경우 project.pbxproj도 함께 커밋해줘야 한다.
• 프로젝트 파일들의 변경점을 확인한 뒤, 함께 커밋해주기! :)

 

 

 

Xcode에 파일 추가하기

1. Destination

- Copy items if needed

파일을 복사하여 추가하는 옵션 - 체크하는 것이 좋다. (Copy by Value같은 개념)

이 옵션 없이 추가한다면 프로젝트 폴더로 복사되지 않고 원본의 레퍼런스를 참조 -> 원본의 폴더가 변경되거나 삭제될 때 더 이상 해당 파일을 사용할 수 없게 된다.

+ 내 project.pbxproj 파일에는 반영이 되어 있지만 이대로 git에 커밋하게 된다면, 다른 사람들에게는 해당 파일이 존재하지 않아 오류가 발생할 수 있다.

 

 

2. Added folders

- 파일 추가

해당 옵션은 'Added folders' 옵션으로, 파일 추가에 대해서는 두 옵션에 대한 차이가 없다. 

 

- 폴더 추가

1) Create groups

• 노란 폴더가 생성된다.
• 가상 폴더의 개념으로 파일 시스템(Finder)을 의미하지 않는다.
• Finder에서 폴더 내에 파일을 추가해도 프로젝트 폴더 내에는 반영되지 않는다.
• Finder에서 폴더의 이름을 변경해도 프로젝트 내에서 폴더가 남아 있다. (내부 파일은 사용할 수 없다.)
• Finder에서 폴더를 삭제해도 프로젝트 내에 폴더는 남아 있다. (내부 파일은 사용할 수 없다.)

2) Create folder references

• 파란 폴더가 생성된다.
• 파일 시스템(Finder)의 폴더에 일대일 맵핑된다. 따라서, 변경 내역이 반영된다.
• Finder에서 폴더 내에 파일을 추가하면 프로젝트 폴더 내에도 파일이 추가된다.
• Finder에서 폴더의 이름을 변경하면 프로젝트 내에서 폴더가 삭제된다.
• Finder에서 폴더를 삭제하면 프로젝트 내에서도 폴더가 삭제된다.
• 나는 주로 파란 폴더로 사용했었다.

 

 

 

Xcode에서 파일 삭제하기

- Remove Reference

파일에 대한 참조만 제거된다. 따라서 파일 추가 시 Copy items if needed 옵션을 선택하지 않았다면, 참조만 제거하여도 상관없다.

만약 Copy items if needed 옵션을 선택하여 추가했는데, Remove Reference로 제거한다면 실제 프로젝트 폴더에 파일은 남아있지만, 참조만 제거가 된 상태이다. 남은 파일은 Finder에서 직접 삭제할 수 있다.

 

- Move to Trash

파일에 대한 참조와 함께 Finder에서 확인할 수 있는 물리적인 파일까지 함께 제거된다.

 

 

 

Understand why merge conflicts happen

Version control systems, like git, auto-magically manage code contributions. It identifies the change, when it occurred, who made it, and on what line so that developers can easily track the history of their codebase.
However, git sometimes gets confused in the following situations:

• When more than one person changes the same line in a file and tries to merge the change to the same branch
• When a developer deletes a file, but another developer edits it, and they both try to merge their changes to the same branch.
• When a developer deletes a line, but another developer edits it, and they both try to merge their changes to the same branch
• When a developer is cherry-picking a commit, which is the act of picking a commit from a branch and applying it to another
• When a developer is rebasing a branch, which is the process of moving a sequence of commits to a base commit

Git is unsure which change to apply, so it leans on the developer for help and notifies them of a merge conflict. Your job is to help git determine which proposed change is most accurate and up to date.

 

 

 

The benefits of preventing merge conflicts

Sometimes, doing that upfront work for your team or yourself to avoid merge conflicts may seem tedious, but it's worthwhile. Using guard rails to prevent merge conflicts will save time and increase developer happiness. Solving a bug, writing a new feature, or scripting automation is time-consuming. Adding the barrier of debugging and resolving a merge conflict means it takes longer to merge to 'main' and longer to deploy to production. Also, if your team is constantly experiencing conflicts, they'll eventually feel disenchanted with their work.

 

Four ways to prevent merge conflicts

1. Standardize formatting rules.
2. Make small commits and frequently review pull requests.
3. Rebase, rebase, rebase (early and often)
4. Pay attention and communicate.

 

 

 

✳️ Four ways to prevent merge conflicts

Standardize formatting rules

Many times conflicts occur because of formatting discrepancies. For example, a technologist inadvertently added extra white space on the same line where another developer added new code. Also, people have different coding styles. For instance, some JavaScript developers use semicolons, but some don't. If you're working on a team, enforce code formatters and linting rules. Make sure everyone on the team is aware of these rules and tools to reduce the number of merge conflicts you experience due to formatting.

Make small commits and frequently review pull requests

I'm going to admit something super embarrassing. Back in the day (~3 years ago), I would make pull requests changing over 50 files, and then I would get annoyed that I had so many merge conflicts. (와우) In hindsight, I was wrong. Changing over 50 files in less than two weeks increased the chances that other developers also made updates to those files.

Also, creating large pull requests discouraged my teammates from thoroughly and quickly reviewing my code. My pull request would sit longer than necessary because it was a behemoth my teammates preferred to avoid.

Take my mistakes as a lesson to make small changes, commit them, and have folks review the pull request as soon as they are available. This way, you'll have fewer chances to change files that other teammates are simultaneously working on. 

Rebase, rebase, rebase (early and often)

I learned about rebasing in 2019 from a coworker that my team dubbed the "Git-tator" (Git and dictator combined). He was earnest about improving our startup's git history and reducing the number of blockers we experienced due to merge conflicts. Arguments ensued because many developers were often working on extensive features simultaneously. We even argued over simple conflicts when people imported new dependencies for different features in the same file on the same line. Thus, he introduced us to rebasing, which significantly improved our software development workflow.

What is rebasing?

The git rebase command reapplies changes from one branch into another, which is very similar to the git merge command. However, in this case, git rebase rewrites the commit history to produce a straight, linear succession of commits.

How rebasing helps prevent merge conflicts

Rebasing is not going to magically remove all merge conflicts. In fact, you may encounter conflicts while rebasing. Sometimes, you will have to repeatedly resolve the same conflict while rebasing. However, merge conflicts happen because multiple changes happen to the same chunk of code simultaneously. If you rebase your local working branch with the default branch (main or master), you're rewriting your local commit history with the default branch's history and then reapplying your changes. In many situations, rebasing first and then merging can make teamwork easier. Rebasing is an option, but not the only solution.(dev-dev-my branch랑 다른걸까? 뭐지?) 

Be careful with rebasing

Be warned – there are moments when rebasing is not recommended. Rebasing is dangerous because you're rewriting history. When rebasing, pay attention to the changes you're accepting because you risk overwriting teammates' changes or including files your teammates intended to delete. You also probably wouldn't want to rebase a public repository on the main branch because that would inaccurately rewrite the history.

If you're new to rebasing or nervous about rebasing, pair with a teammate to sanity check.

How I rebase to avoid merge conflicts

There's no correct workflow – just preferred ones.
Here's the workflow I follow as determined by teams and codebases I’ve worked in:

• If I'm working with more than one person, I'll create a feature branch from the default branch.
  This way, we can contribute to the feature branch in tandem.
• I'll make a new local branch from the default or feature branch
• I'll add and commit new changes to my local branch
• I'll rebase updates from the default or feature branch
• I'll merge changes from my local branch to the default or feature branch

Pay attention and communicate

No git command or software tool can replace the need for communication in engineering teams. Being a good software developer and collaborator goes beyond writing code. Good software developers communicate with teammates. Keep your team aware of what files you will be touching and coordinate with your Product Manager and SCRUM Master to avoid working on features that conflict with other features. 

If you're working alone, pretend you're working on a team by:

• creating branches 
• creating pull requests
• Avoid allowing pull requests to become stale
• Make sure you're not changing the same lines of code before merging a prior change
• Establish and follow formatting rules 

Working alone shouldn't stop you from practicing healthy coding habits, so try to keep your codebase clean!
Your codebase may turn into an open source project or a project that you show off in interviews.

 

 

 

 

 

 

 

출처

• https://developer.apple.com/library/archive/featuredarticles/XcodeConcepts/Concept-Projects.html
• https://hcn1519.github.io/articles/2018-06/xcodeconfiguration
• https://isjang98.github.io/blog/Merge-conflicts-project-pbxproj
• https://velog.io/@honghoker/git-Xcode-pbxproj-merge-conflict-문제-해결-방법
• https://ios-development.tistory.com/406
• https://dev.to/github/how-to-prevent-merge-conflicts-or-at-least-have-less-of-them-109p
• https://nazan9.tistory.com/7
• https://git-scm.com/book/ko/v2/Git-브랜치-Rebase-하기