已知单个Android项目改包名方法，如何在文件差异大的所有分支修改？

Got it, let’s break down how to update your Android project’s package name across all Git branches—even when those branches have wildly different file structures. I’ve helped teams tackle this exact problem, so here’s a practical, step-by-step approach:

The key here is to automate what you can, and reserve manual work for branches with unique file layouts that scripts can’t handle reliably.

1. Lock Down Your Single-Branch Package Name Workflow First #

Before scaling to all branches, make sure you have a repeatable process for a single branch. For most Android projects, this includes:

• Using Android Studio’s Refactor > Rename (select "Rename package") to handle code files, manifest entries, and resource references automatically.
• Or, if you prefer scripting:
  • Replacing the old package name in AndroidManifest.xml, module-level build.gradle, project-level build.gradle, and proguard-rules.pro.
  • Renaming the directory structure for Java/Kotlin sources (e.g., com/old/package → com/new/package).
  • Updating package declarations in all .java/.kt files.
  • Checking for hardcoded package names in strings, test files, or third-party configs.

Document this process clearly—you’ll reuse parts of it for automation and manual fixes.

2. Automate Package Name Changes for Most Branches #

For branches with standard Android project structure, a bash script can save you hours. Here’s a robust example (run this in Git Bash if you’re on Windows):

#!/bin/bash

# Set your old and new package names
OLD_PACKAGE="com.original.package"
NEW_PACKAGE="com.updated.package"

# Backup your repo first! Uncomment below to create a local backup
# git clone . ../package-name-backup

# Iterate over all local branches
for branch in $(git branch --format='%(refname:short)'); do
    echo "=== Processing branch: $branch ==="
    git checkout $branch

    # Step 1: Replace package name in text files (manifest, gradle, proguard, strings)
    grep -rl "$OLD_PACKAGE" --include="*.xml" --include="*.gradle" --include="*.pro" . | xargs sed -i "s/$OLD_PACKAGE/$NEW_PACKAGE/g"

    # Step 2: Rename source directory structure
    OLD_SRC_DIR=$(echo $OLD_PACKAGE | tr '.' '/')
    NEW_SRC_DIR=$(echo $NEW_PACKAGE | tr '.' '/')
    # Create parent directories if needed
    mkdir -p app/src/main/java/$(dirname $NEW_SRC_DIR)
    # Move the old package directory to the new path
    if [ -d "app/src/main/java/$OLD_SRC_DIR" ]; then
        mv app/src/main/java/$OLD_SRC_DIR app/src/main/java/$NEW_SRC_DIR
    fi

    # Step 3: Update package declarations in Java/Kotlin files
    grep -rl "$OLD_PACKAGE" --include="*.java" --include="*.kt" app/src/main/java/$NEW_SRC_DIR | xargs sed -i "s/$OLD_PACKAGE/$NEW_PACKAGE/g"

    # Commit changes if anything was modified
    if ! git diff --quiet; then
        git add .
        git commit -m "Refactor: Update package name to $NEW_PACKAGE"
        echo "✅ Changes committed for $branch"
    else
        echo "⚠️ No changes needed for $branch"
    fi
    echo ""
done

# Switch back to your default branch (adjust to your main branch name)
git checkout main

Notes on the script: #

• Adjust paths: If you have a multi-module project, add paths for other modules (e.g., feature/src/main/java/).
• Test first: Run this on a throwaway test branch before applying to all branches to catch edge cases.
• Handle Windows line endings: If sed causes issues, use sed -i.bak to create backups, then delete .bak files afterward.

3. Manually Handle Branches With Significant File Differences #

For branches with non-standard layouts (e.g., old project versions with different manifest locations, missing gradle files, or custom build setups):

1. Flag these branches: Add a check in your script to skip branches that don’t match the standard structure (e.g., if app/src/main/AndroidManifest.xml doesn’t exist).
2. Use Android Studio’s refactoring: Switch to the branch, open the project in Android Studio, and use Refactor > Rename on the package. This tool intelligently scans all files in the project, even non-standard ones, to update references.
3. Compile and test: After refactoring, build the project to catch any missed references (like hardcoded package names in test files or debug configs).
4. Commit and push: Once everything works, commit the changes with a clear message.

4. Push Changes to Remote #

After processing all local branches, push the updates to your remote repo:

for branch in $(git branch --format='%(refname:short)'); do
    git push origin $branch
done

• Warning: If remote branches have new commits from teammates, pull those changes first and resolve conflicts before pushing. Avoid git push --force unless you’re sure no one else is working on those branches.

Pro Tips to Avoid Headaches #

• Backup everything: Always clone your repo to a backup location before running bulk scripts.
• Track progress: Keep a list of branches you’ve processed to avoid missing any.
• Communicate with your team: Let teammates know you’re updating package names across branches so they don’t push conflicting changes mid-process.

内容的提问来源于stack exchange，提问作者Yuganka Sharan