Developer’s daily workflow: commit, push, and .gitignore

1. Getting started: cloning the 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 on 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 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 right from the IDE. To do this, choose Log in to GitHub. Your IDE will open a browser for authorization.

On the page that opens, confidently click the green Authorize JetBrains button. After that, you’ll be able to select your repositories directly from the list in the IDE. Choose the desired project and click Clone.

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

Step 4. Antivirus setup (for Windows users)

Windows antivirus may warn that the IDE is attempting actions it doesn’t 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 on its own.

2. Saving changes: commit

A commit is a “snapshot,” or a saved state of your project at a specific moment in time. Think of it as a save point in a game: you can always return to it if something goes wrong. Each 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"
    
        

Commit history. Each new commit builds on the previous one, creating a chronological evolution of the project.

Step 1. Make changes.

If you cloned a newly created repository, it will contain only one file — README.md

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

Step 2. Open the Commit window.

There is a Commit tab on the left side of the IDE. When you open it, you’ll see all the changes ready to be saved. For the very first commit, this window deserves special attention.

Let’s break down what we see:

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

A question may arise: do you need to add all these service files to the repository?

The good news is that when we created the repository on GitHub, we chose a .gitignore template. This file already contains rules that tell Git to ignore unnecessary folders or files. But we’ll talk more about this at the end of the lecture.

For now, our task for the first commit is to add all the main project files to history and write the commit message itself.

Step 3. Make a commit.

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

3. Pushing changes to GitHub: Push

Your commits are currently stored only on your computer. To share them with the team or keep them in a safe place, you need to push 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 have been copied
and safely stored on the server.
    
        

Step 1. Click the Push button.

In the upper-right corner of the IDE there is a green upward arrow — the Push button. Click it.

Step 2. Review and confirm.

A window will open where you’ll see all the commits ready to be pushed. This is your last chance to make sure you’re pushing exactly what you intend to. Click Push.

If everything went well, you will see messages: 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. You’ll see your changes there.

4. Git control panel

Your IDE has a special Git menu located in the top bar. This is your version control hub. Let’s quickly get familiar with its key items.

• Commit: opens the window you already know for saving changes.
• Push: opens a window to push your commits to GitHub.
• Update Project: a very important feature. It downloads the latest changes from other team members (performs git pull). Click it every morning before you start working!
• Branches: opens the window for managing branches. We’ll explore this in detail in the next lecture.
• Show Git Log: shows the entire commit history of your project. Your personal time machine.

5. Using .gitignore files

If you’ve added some service files to your project and don’t want them to accidentally end up in the repository, you can add them to exclusions. There’s a file named .gitignore for this. It’s very convenient when the project has files that shouldn’t be stored in version control (for example, temporary files, logs, passwords).

Step 1. First, create a file in the project directory that you want to ignore. For example, notes.txt. After creating the file, click Cancel if the IDE suggests adding it to Git.

Step 2. Right-click the created file in the “Project” window. Go to Git --> Add to .gitignore --> Add to .gitignore. This option adds the selected file to the .gitignore file at the root of your project.

If you didn’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 adding to .gitignore, ignored files will be shown in gray or brown. When you try to commit changes, these files will be ignored. You can add the .idea folder to the ignore list.

Don’t forget to commit the .gitignore file itself to the repository and push the changes to GitHub so that all project members use the same ignore rules.

Excluding local files: .git/info/exclude

In addition to the .gitignore file, which is used to exclude files for all users of the project, Git provides the ability to create local ignore rules in .git/info/exclude. They won’t be committed to the repository and will apply only to your local copy of the project.

This can be useful, for example, for ignoring files created by your IDE that shouldn’t go into version control but are specific only to you.

Important! Local ignore rules apply only to your local copy of the repository.

What if I’ve already committed it?

.gitignore ignores only new, untracked files. If you’ve already committed a file, it’s in the repository history, and Git will continue tracking it even if you add it to .gitignore. For such situations, there’s a terminal command: git rm --cached <file>. But you’ll need to read about it separately.

Rules for .gitignore

The .gitignore file specifies filename and folder patterns that Git should ignore.

Empty lines are ignored. To add a comment, start the line with the # character.

Patterns:

• * — 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, logs/ ignores all contents of the logs folder.
• ! — at the beginning of a line negates a rule. For example, if you have a rule *.log but want to track important.log, add the line !important.log.
• ** — matches any number of nested folders. For example, **/temp ignores temp folders at any nesting level.

Example .gitignore file

# Compiled code
/bin/
/obj/

# Temporary files
*.tmp
*.swp

# Logs
*.log

# IDE-generated folders
.idea/
*.user
*.suo

# Virtual environments and dependencies
/venv/
/node_modules/

Ready-made templates

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

1. The .gitignore collection by GitHub for different languages and frameworks: https://github.com/github/gitignore.
2. gitignore.io — a handy web service that generates a .gitignore file for your tech stack.