Developer daily workflow: Commit, Push, and .gitignore

1. Getting started: cloning a project

Let’s start from where we left off in the previous lecture. You have a repository created on GitHub, and now you need to get its local copy onto your computer to begin working. This process is called cloning.

Step 1. Launch your IDE. If you have a project open, close it via File | Close Project. On the start window (Welcome Screen), choose Clone Repository (or Get from VCS).

Step 2. In the window that opens, paste the URL of your repository. This method is useful if you are cloning someone else’s repository. You can copy the URL from the repository page on GitHub.

If you are cloning your own repository (our case), the easiest way is to sign in to your GitHub account directly from the IDE. To do that, select Log in to GitHub. Your IDE will open a browser for authorization.

On the page that opens, confidently click the green button Authorize JetBrains. After that, you will be able to pick your repositories directly from the list in the IDE. Select the required project and click Clone.

Step 3. Your IDE will ask whether you trust this project. Since this is your own repository, click Trust Project.

Step 4. Antivirus setup (for Windows users)

Windows antivirus may warn you that the IDE is trying to perform actions it does not recognize. Since we are going to create and run programs, we need to allow the IDE to work without restrictions. Click the “Automatically” button so the IDE can add the required folders to the antivirus exclusions by itself.

2. Saving changes: Commit

commit is a “snapshot”, or a saved state of your project at a specific moment in time. Think of it like a save point in a game: you can always come back to it if something goes wrong. Every commit has a unique identifier and a message describing the changes made.

        gitGraph
        commit id: "Initial commit"
        commit id: "Add user authentication"
        commit id: "Fix login button bug"
        commit id: "Refactor database connection"
    

Step 1. Make changes.

If you cloned a newly created repository, it will contain only one file — README.md (and hidden IDE folders).

Open README.md and add a description of your project. As soon as you start editing the file, the IDE will highlight its name in blue in the Project tool window. This means the file has been modified, but the changes have not been saved to Git yet. The IDE will add a green line where you made changes.

Step 2. Open the Commit window.

On the left side of the IDE there is a Commit tab. Opening it, you will see all changes that are ready to be saved. This is your Staging Area.

Let’s break down what we see:

• Changes: these are files that are already tracked by Git but have been modified. In our case, it is README.md, where we added the project plan.
• Unversioned Files: these are new files that Git sees in the project folder but is not tracking yet.

Important

Before you click the Commit button, always visually check which files have checkmarks next to them. This is especially important for the first commit.

If you see the Unversioned Files list contains the .idea/ folder (and especially the workspace.xml file, which changes with every mouse click) or the build/ folder — stop! These service files must not get into the shared history. The good news: if you created the repository with a .gitignore template, Git will hide these folders automatically. If they are visible, you urgently need to add them to ignore rules (more on that at the end of the lecture).

For now, our task for the first commit is to check the main project files and write a clear message in the Commit Message field.

Step 3. Make a commit.

Click the blue Commit button. Done! You saved a “snapshot” of your project in the local repository. The file name will return to its normal color.

3. Sending changes to GitHub: Push

Your commits are still stored only on your computer. To share them with the team or keep them in a safe place, you need to send them to the remote GitHub repository.

        sequenceDiagram
        participant Local repository (Your computer)
        participant Remote repository (GitHub)

        note over Local repository (Your computer): You made one or more commits.
They exist only here.

        Local repository (Your computer) ->> Remote repository (GitHub): git push (send commits)

        note over Remote repository (GitHub): Your commits are copied
and safely stored on the server.
    

Step 1. Click the Push button.

In the UI, the Push button is on the main top toolbar (Main Toolbar). It looks like an arrow pointing up and to the right. Click it.

Step 2. Review and confirm.

A window will open where you will see all commits that are ready to be sent. This is your last chance to make sure you are sending exactly what you intend. Click Push.

If everything went well, you will see an IDE popup notification: Pushed commits to origin/main. Create pull request.

Step 3. Check the result on GitHub.

After a successful push, open your repository page on GitHub in a browser. You will see that your changes and files have appeared there.

4. Git control panel

Your IDE has a dedicated Git tool window, as well as quick actions on the top Main Toolbar. This is your version control command center. Let’s get familiar with the key buttons.

• Commit (checkmark): opens the panel for saving changes.
• Push (up/right arrow): opens the window for sending your commits to GitHub.
• Branches: opens the branch management widget (in the upper-left corner).
• Show Git Log: shows the entire commit history of your project on the Git tab. Your personal time machine.

The morning starts with Update Project

The Update Project button performs a critical function — it downloads the latest changes from other team members from the GitHub server to your computer (runs git pull).

Make it a habit: every morning, before you write even a single line of new code, press this button. If you start working with outdated code while your colleagues have already made changes in the same files, by lunchtime you may end up with a complicated merge conflict.

5. Using .gitignore files

If service files or compilation results appear in your project and you don’t want them to accidentally end up in the repository, you need to add them to exclusions. To do this, a special file named .gitignore is created in the project root.

Kotlin specifics and why we ignore folders

In the Kotlin world, the de facto standard build system is Gradle, and the primary development environment is IntelliJ IDEA. They generate many service files that must never be pushed to Git:

• build/ — this is where the results of compiling your code are stored (.class files, .jar archives). They can be tens or hundreds of megabytes, and the build tool regenerates them on each developer’s machine. Storing them in Git means quickly running out of space on the server.
• .gradle/ — the local cache of the build system.
• .idea/ — local IDE window settings (which files you have open, font size, paths to local SDKs). Your colleagues don’t need your personal UI settings, and the workspace.xml file changes literally all the time.

How to add a file to ignore manually:

Step 1. Suppose you created a temporary file notes.txt with passwords to a test database. Right-click it in the Project tool window.

Step 2. Go to the Git menu -> Add to .gitignore -> Add to .gitignore. This option adds the selected file to the .gitignore file in your project root.

If you don’t have a .gitignore file yet, the IDE will suggest creating one. Agree.

Step 3. Your IDE will automatically add the file name to .gitignore.

After that, ignored files will be shown in the project tree in gray or olive. When you try to make a commit, Git simply “won’t see” these files. The key thing is — don’t forget to commit the .gitignore file itself, so all team members will download these ignore rules.

What if I already committed it?

.gitignore ignores only new files that are not tracked yet. If you accidentally already committed the build/ folder, it is in history, and Git will continue tracking it even if you add it to .gitignore. In such cases, you will need to clear the cache (for example, with git rm -r --cached build/ in the terminal), but it’s better to avoid letting junk into the first commit in the first place.

Rules for .gitignore

The .gitignore file contains patterns for file and folder names that Git should ignore. Empty lines are ignored. To add a comment, start the line with the # character.

• * — matches any number of any characters. For example, *.log ignores all files with the .log extension.
• / — at the end of a pattern means a directory. For example, build/ ignores all contents of the build folder.
• ! — at the beginning of a line negates the rule. For example, if you have a *.log rule but you want to track important.log, add !important.log.
• ** — matches any number of nested folders.

Example .gitignore file for Kotlin and Gradle

# Gradle compilation and build outputs
build/
.gradle/
out/

# Local IDE files and settings
.idea/
*.iml
*.iws

# Operating system files
.DS_Store
Thumbs.db

# Logs
*.log

Ready-made templates

You don’t need to write these files from scratch. There are ready-made templates verified by the community:

1. GitHub’s .gitignore collection for different languages and frameworks: https://github.com/github/gitignore.
2. gitignore.io — a convenient web service that generates a .gitignore file for your technologies (just type Kotlin, Gradle, Intellij).