Developer's Daily Routine: Commit, Push, and .gitignore

1. Getting Started: Cloning a Project

Let's pick up where we left off in the last lecture. You have a repository created on GitHub, and now you need to get a local copy of it on your computer to start working. This process is called cloning.

Step 1. Launch your IDE. If you have any project open, close it via File | Close Project. On the Welcome Screen, select 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. The URL can be copied from the repository page on GitHub.

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

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

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

Step 4. Antivirus Configuration (for Windows users)

Windows antivirus might warn you that the IDE is trying to perform unknown actions. 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 necessary folders to the antivirus exclusions itself.

2. Saving Changes: Commit

A commit is a "snapshot," or a saved state of your project at a specific point in time. Think of it like a save point in a game: you can always return 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 freshly created repository, it will only contain one file — README.md (and hidden IDE folders).

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 pane. This means the file has been modified, but the changes haven't been saved in 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 is the Commit tab. Opening it, you'll see all changes ready to be saved. This is your Staging Area.

Let's break down what we see:

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

Important

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

If you see in the Unversioned Files list the .idea/ folder (and especially the workspace.xml file, which changes with every mouse click) or folders named bin/, vendor/, as well as compiled binary files (for example, myapp.exe) — stop! These service files should not end up in the general history. The good news is: if you created the repository with a .gitignore template (Go), Git itself will hide these folders. If they are visible, they urgently need to be added to ignore (more on this at the end of the lecture).

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

Step 3. Make the commit.

Click the blue Commit button. Done! You have 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 currently stored only on your computer. To share them with your team or save them in a secure 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 are copied
and safely stored on the server.
    

Step 1. Click the Push button.

In the interface, the Push button is located on the Main Toolbar at the top. 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 the commits ready to be sent. This is your last chance to ensure you are pushing exactly what is needed. Click Push.

If everything went successfully, you will see a pop-up IDE 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 your changes and files have appeared there.

4. Git Control Panel

Your IDE has a separate 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 to save changes.
• Push (arrow up/right): opens the window to send your commits to GitHub.
• Branches: opens the branch management widget (in the top left corner).
• Show Git Log: displays the entire commit history of your project in the Git tab. Your personal time machine.

The Morning Starts with Update Project

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

Make it a habit: every morning, before writing a single line of new code, click this button. If you start working with old code while your colleagues have already made changes to the same files, by lunchtime you will face a complex merge conflict.

5. Using .gitignore Files

If service files or compilation results appear in your project, and you don't want them to accidentally get into the repository, they need to be added to exceptions. For this, a special file named .gitignore is created in the project root.

Go Specifics and What We Ignore

In the Go ecosystem, compilation and testing are performed by built-in tools (go build, go test). The process of building and running tests creates binary files and caches that are strictly forbidden to be sent to Git:

• bin/ or out/ — folders where you can put ready compiled programs. They are unique to your operating system and processor architecture.
• *.exe, files without extensions (in Linux/macOS) — the binary executable files themselves. Storing them in Git is bad form: they take up space and are useless to other developers (since they are compiled for your specific OS).
• *.test, *.out — binaries created during tests, and code profiling/coverage files (for example, coverage.out).
• go.work and go.work.sum — local workspace files. Unlike go.mod and go.sum, which must be in the repository, go.work files are intended solely for your personal local convenience.
• vendor/ — directory with local copies of dependencies. In modern Go module projects, it's often ignored, entrusting package downloading to the go mod utility.
• .idea/ — local IDE window settings (which files you have open, font size). Your colleagues don't need your personal interface settings, and the workspace.xml file generally changes every second.

How to manually add a file to ignore:

Step 1. Suppose you created a temporary file notes.txt with passwords to a test database. Right-click on it in the project 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 the root of your project.

If you don't have a .gitignore file yet, the IDE will offer to create one. Agree.

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

After that, the ignored files will be displayed in the project tree in gray or olive color. When trying to commit, Git will simply "not see" these files. The main thing is don't forget to commit the .gitignore file itself, so that these ignore rules are downloaded by all members of your team.

But what if I already committed it?

.gitignore only ignores new, untracked files. If you mistakenly already committed the bin/ folder, it's in the history, and Git will continue tracking it even if you add it to .gitignore. For such situations, you will need to clear the cache (for example, with the command git rm -r --cached bin/ in the terminal), but it's better just not to let garbage get into the first commit.

Rules for .gitignore

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

• * — replaces 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 inverts the rule. For example, if you have a rule *.log, but you want to track important.log, add the line !important.log.
• ** — matches any number of nested folders.

Example .gitignore file for Go

# Compiled binary files
*.exe
*.exe~
*.dll
*.so
*.dylib
bin/

# Testing and profiling files
*.test
*.out

# Go local workspace files
go.work
go.work.sum

# Directory with local copies of dependencies (optional)
vendor/

# Local IDE files and settings
.idea/

# Operating system files
.DS_Store
Thumbs.db

Ready-made templates

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

1. GitHub's .gitignore collection for various 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 Go, GoLand, Intellij).