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 start 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 opened window paste the URL of your repository. This way is useful if you're cloning someone else's repo. The URL can be copied from the repository page on GitHub.
If you're cloning your own repo (our case), it's easiest to sign in to your GitHub account directly from the IDE. Choose the Log in to GitHub option. Your IDE will open the browser for authorization.
On the opened page confidently click the green button Authorize JetBrains. After that you’ll be able to pick your repositories right from the list in the IDE. Select the project you need and press Clone.
Step 3. Your IDE will ask whether you trust this project. Since it's your own repo, click Trust Project.
Step 4. Antivirus setup (for Windows users)
Windows antivirus may warn that the IDE is trying to do actions it doesn't recognize. Since we're going to create and run programs, we need to allow the IDE to operate without restrictions. Click the "Automatically" button so the IDE adds the needed folders to the antivirus exceptions.
2. Saving changes: Commit
commit is a "snapshot", or a saved state of your project at a certain moment. Think of it like a save point in a game: you can always go back to it if something goes wrong. Every commit has a unique id and a message describing the changes.
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 history of the project.
Step 1. Make changes.
If you cloned a freshly created repository, it will contain only one file — README.md
Open the README.md file and add a description of your project. Once you start editing the file, the IDE will highlight its name in blue in the project panel. That means the file was changed but changes are not yet saved to Git. The IDE will add a green gutter where you made changes.
Step 2. Open the Commit window.
On the left in the IDE there's a Commit tab. Open it and you'll see all changes ready to be saved. For the very first commit this window needs special attention.
Let's break down what we see:
- Changes: these are files that are already tracked by Git but were modified. In our case it's
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.
You might wonder: should you add all those service files to the repo?
The good news is that when we created the repo on GitHub we chose a .gitignore template. That file already contains rules telling Git to ignore unnecessary folders or files. We'll talk about that in detail 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.
Step 3. Make the commit.
Click the Commit button. Done! You saved a "snapshot" of your project in the local repository. The file will go back to normal color.
3. Pushing changes to GitHub: Push
Your commits currently live only on your computer. To share them with the team or back them up, you need to send them to the remote repository on GitHub.
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 top-right corner of the IDE there's a green up-arrow — that's the Push button. Click it.
Step 2. Review and confirm.
A window will open where you'll see all commits ready to be sent. This is your last chance to make sure you're pushing exactly what you want. Click Push.
If everything went well, you'll 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 in the top bar. This is your version control hub. Let's quickly go through its key items.
Commit: opens the familiar commit window to save changes.Push: opens the window to send your commits to GitHub.Update Project: a very important feature. It fetches fresh changes from other team members (performsgit pull). Run it every morning before you start working!Branches: opens the branch management window. We'll cover this in detail in the next lecture.Show Git Log: shows the full commit history of your project. Your personal time machine.
5. Using .gitignore files
If you added some service files to your project and don't want them to accidentally end up in the repo, you can add them to ignore rules. For that there's a file named .gitignore. It's super handy when the project has files that shouldn't be stored in version control (like temp files, logs, passwords).
Step 1. First create the file in the project directory you want to ignore. For example, notes.txt. After creating the file press Cancel if the IDE offers to add it to Git.
Step 2. Right-click the created file in the "Project" view. Go to Git --> Add to .gitignore --> Add to .gitignore. This option adds the selected file to the .gitignore in the root of your project.
If you didn't have a .gitignore file yet, the IDE will offer to create it. Agree.
Step 3. Your IDE will automatically add the filename to .gitignore.
After adding to .gitignore ignored files will be shown in gray or brown. When you try to commit changes those files will be ignored. You can add the .idea folder to ignore.
Don't forget to commit the .gitignore file itself to the repo and push the changes to GitHub so everyone on the project uses the same ignore rules.
Ignoring local files: .git/info/exclude
Besides the .gitignore file, which is used to exclude files for all project users, Git provides the ability to create local ignore rules in .git/info/exclude. These won't be committed to the repo and will apply only to your local copy of the project.
This can be useful, for example, to ignore files created by your IDE that shouldn't be in version control but are specific to you.
Important! Local ignore rules apply only to your local copy of the repository.
What if I already committed it?
.gitignore ignores only new, untracked files. If you 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 cases there's a terminal command: git rm --cached <file>. But that's something to read about separately.
Rules for .gitignore
In the .gitignore file you list patterns of filenames and folders that Git should ignore.
Empty lines are ignored. To add a comment start the line with #.
Patterns:
*— matches any number of any characters. For example,*.logignores all files with the.logextension./— at the end of a pattern denotes a directory. For example,logs/ignores all contents of thelogsfolder.!— at the start of a line negates the rule. For example, if you have*.logbut want to trackimportant.log, add!important.log.**— matches any number of nested folders. For example,**/tempignorestempfolders at any depth.
Example .gitignore file
# Compiled code
/bin/
/obj/
# Temporary files
*.tmp
*.swp
# Logs
*.log
# IDE folders
.idea/
*.user
*.suo
# Virtual envs and dependencies
/venv/
/node_modules/
Ready-made templates
You don't have to write these files from scratch. There are community-vetted templates:
- GitHub's
.gitignorecollection for different languages and frameworks: https://github.com/github/gitignore. - gitignore.io — a handy web service that generates a
.gitignorefor your tech stack.
GO TO FULL VERSION