Git Cheatsheet for Android Development with Android Studio Terminal

Let’s dive into some detailed examples for common scenarios and setups in Android development with Git and Android Studio terminal:

1. Setting Up a New Android Project with Git

Let’s say you’re starting a new Android project and you want to set up a Git repository from the beginning.

Steps:

1. Initialize the Git repository: Inside your Android project folder, run:

   git init
   
   

2. Create a .gitignore file: Android projects usually include .gitignore files to prevent certain files from being tracked, like build files and IDE configurations. Here’s a basic .gitignore for Android:

   # Android
   .gradle/
   .idea/
   *.iml
   build/
   *.apk
   *.log
   local.properties
   
   

   You can create this file manually or use GitHub’s or GitLab’s default Android .gitignore template.

3. Add all files to the staging area:

   git add .
   
   

4. Commit the initial project setup:

   git commit -m "Initial commit of Android project"
   
   

5. Set the remote repository: First, create a repository on GitHub or GitLab, and then add the remote URL to your project:

   git remote add origin <repository_url>
   
   

6. Push the code to the remote repository:

   git push -u origin master
   
   

2. Working with Branches in Android Studio

Let’s walk through the process of creating a new branch for a feature and pushing it to Git.

Steps:

1. Create a new feature branch: Use this command to create and switch to a new branch:

   git checkout -b feature/user-login
   
   

2. Make your changes in Android Studio: After implementing the feature (e.g., creating a user login screen), add the files to the staging area:

   git add .
   
   

3. Commit the changes:

   git commit -m "Implemented user login screen"
   
   

4. Push the branch to the remote repository:

   git push origin feature/user-login
   
   

5. Create a Pull Request (PR) on GitHub/GitLab: Once the branch is pushed, you can create a PR from the GitHub/GitLab interface to merge it into the main or develop branch.

3. Merging a Branch into main Branch

After your feature branch is complete and has been tested, it’s time to merge it into the main branch.

Steps:

1. Switch to the main branch:

   git checkout main
   
   

2. Pull the latest changes from the remote main branch:

   git pull origin main
   

3. Merge the feature branch into main:

   git merge feature/user-login
   
   

4. Resolve any merge conflicts (if any), and then commit the merge:

   git commit -m "Merged feature/user-login into main"
   
   

5. Push the changes to the remote repository:

   git push origin main
   
   

4. Reverting or Undoing Changes

If you made a mistake or want to discard changes, you can use git reset or git checkout:

Example 1: Undo the last commit (keep changes in working directory):

git reset --soft HEAD~1

Example 2: Undo changes in a specific file:

git checkout -- path/to/file

Example 3: Undo staged changes:

git reset path/to/file

5. Working with Git in Android Studio Terminal

You can also use Android Studio’s integrated terminal to run these commands, which makes it easier to work with both Android-specific tasks and Git commands without leaving the IDE.

Example 1: Building and Running Your Android Project Using Gradle

1. Clean your project:

   ./gradlew clean   # On Unix-based systems
   gradlew clean     # On Windows
   
   

2. Build the APK:

   ./gradlew assembleDebug
   
   

3. Install and run the app on a connected device or emulator:

   ./gradlew installDebug
   
   

4. Run unit tests:

   ./gradlew testDebugUnitTest
   
   

Example 2: Checking Gradle Dependencies

1. List all dependencies in your project:

   ./gradlew dependencies
   

Example 3: Linting Your Android Project for Issues

1. Run lint to check for code quality and possible issues:

   ./gradlew lint
   
   

Example 4: Handling Build Failures

When a build fails, you can view detailed logs in Android Studio. You can also use the terminal to examine issues:

./gradlew build --stacktrace

---

This should cover most common Git workflows and using Android Studio’s terminal for building and managing projects. Let me know if you want to explore any specific command or setup in more detail!

📢 Feedback: Did you find this article helpful? Let me know your thoughts or suggestions for improvements! 😊 please leave a comment below. I’d love to hear from you! 👇

Happy coding! 💻✨

Read More

Setting Up GitHub Actions for Efficient Android App Development

GitHub Actions is a powerful tool for automating workflows in software development. In the context of Android app development, you can use GitHub Actions for Continuous Integration (CI) and Continuous Deployment (CD) to streamline your build, test, and deployment processes. Here's an overview of how Android engineers can set up GitHub Actions in their Android app project:

1. Setting up GitHub Actions for Android CI/CD

Step 1: Create a .github folder in your repository

In your Android project, create a .github folder at the root of your repository.

Step 2: Create a workflow file

Inside the .github folder, create a workflows directory. Inside this directory, create a .yml file (e.g., android.yml). This file will define the CI/CD workflow for your Android app.

Here's an example of a basic GitHub Actions configuration file for an Android project:

name: Android CI

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        java-version: [11]
        android-ndk-version: [22.1.7171670] # Choose the NDK version you need

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up JDK
        uses: actions/setup-java@v2
        with:
          java-version: ${{ matrix.java-version }}

      - name: Set up Android SDK
        uses: android-actions/setup-android@v2
        with:
          api-level: 30  # Set your target Android API level
          ndk-version: ${{ matrix.android-ndk-version }}

      - name: Build with Gradle
        run: ./gradlew build

      - name: Run tests
        run: ./gradlew testDebugUnitTest

      - name: Upload build artifacts
        if: success()
        uses: actions/upload-artifact@v2
        with:
          name: build
          path: app/build/outputs

Key Steps in the Workflow

1. actions/checkout: This action checks out the repository's code so that it can be used in subsequent steps.
2. Set up Java: Android projects require a specific version of Java, and this action sets up Java 11 (as an example) for your project.
3. Set up Android SDK & NDK: This step installs the Android SDK and NDK on the CI machine so it can build Android apps.
4. Build the app with Gradle: This step builds your Android app using Gradle. The ./gradlew build command compiles the app.
5. Run tests: The ./gradlew testDebugUnitTest command runs unit tests for your Android project.
6. Upload artifacts: After a successful build, you can upload artifacts (such as APKs or logs) as build outputs for further use.

2. Additional Steps

You can extend the workflow to include more advanced steps, such as:

• Run UI tests (Espresso): You can add a step to run UI tests using Espresso, similar to how you run unit tests.

  - name: Run UI tests
    run: ./gradlew connectedDebugAndroidTest
  
  

• Deploy to Firebase or Play Store: After building the app and running tests, you can deploy it directly from GitHub Actions using Firebase App Distribution or Google Play's API.

• Code Quality Checks: Before building or deploying, you can integrate tools like Lint, Checkstyle, or Detekt to perform code quality checks.

• Publish Artifact: After a successful build, you can add steps to upload APKs to GitHub Releases or other distribution platforms.

3. Example: Publishing to Firebase App Distribution

To distribute your app to Firebase App Distribution automatically after a successful build, you can add the following steps to your workflow:

      - name: Upload APK to Firebase App Distribution
        uses: wzieba/Firebase-Distribution-Github-Action@v1
        with:
          appId: ${{secrets.FIREBASE_APP_ID}}  # Set this as a secret in GitHub
          token: ${{secrets.FIREBASE_AUTH_TOKEN}}  # Set this as a secret in GitHub
          groups: testers  # Specify the group of testers
          file: app/build/outputs/apk/release/app-release.apk  # Path to your APK

4. Setting Secrets in GitHub

For sensitive data like Firebase credentials, make sure to set them up as secrets in GitHub:

• Navigate to your repository on GitHub.
• Go to Settings > Secrets > New repository secret.
• Add secrets like FIREBASE_APP_ID and FIREBASE_AUTH_TOKEN.

5. Run the Workflow

Once the GitHub Actions workflow file is added, it will run automatically when you push changes to the main branch or create a pull request targeting the main branch.

You can monitor the progress and see the results in the Actions tab of your GitHub repository.

---

This approach will automate your build, test, and deployment processes, making it easier to maintain high-quality Android applications. It also helps with faster feedback on code changes, especially in larger teams.

Reference: https://docs.github.com/en/actions, https://github.com/actions, https://docs.github.com/en/actions/about-github-actions/understanding-github-actions,  https://github.com/marketplace/actions/automated-build-android-app-with-github-action, https://github.com/marketplace/actions/upload-android-release-to-play-store

Read More

What are the differences between git pull and git fetch?

When you are getting confuse in git pull and git fetch, here is the some solutions, may be helpful.

In the simplest terms, git pull does a git fetch followed by a git merge.
You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/<remote>/. This operation never changes any of your own local branches under refs/heads, and is safe to do without changing your working copy. I have even heard of people running git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).


A git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.

or

• When you use pull, Git tries to automatically do your work for you. It is context sensitive, so Git will merge any pulled commits into the branch you are currently working in. pull automatically merges the commits without letting you review them first. If you don’t closely manage your branches you may run into frequent conflicts.
• When you fetch, Git gathers any commits from the target branch that do not exist in your current branch and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date, but are working on something that might break if you update your files. To integrate the commits into your master branch, you use merge.

Read More