Ignoring files and directories in git (.gitignore)

Содержание:

Работа с репозиторием

Полезные горячие клавиши

ctrl + t — получить последние изменения с удаленного репозитория (git pull).
ctrl + k — сделать коммит/посмотреть все изменения, которые есть на данный момент. Сюда входят и untracked, и modified файлы (смотри мою статью про гит, там это описано) (git commit).
ctrl + shift + k — это команда для создания пуша изменений на удаленный репозиторий. Все коммиты, которые были созданы локально и еще не находятся на удаленном, будут предложены для пуша (git push).
alt + ctrl + z — откатить в конкретном файле изменения до состояния последнего созданного коммита в локальном репозитории. Если в левом верхнем углу выделить весь проект, то можно будет откатить изменения всех файлов.

Usage

$ alias gi="git-ignore"

# Depends on fzf
$ gi # then press <Enter>

# Separate params with spaces or commas
$ gi macos linux windows vim emacs >> ./.gitignore

# Overwrite existing .gitignore
$ gi macos,linux,windows vim emacs >| ./.gitignore

New CLI （)

❯ alias gi="git-ignore"

❯ gi -h
git-ignore 1.1.0 by laggardkernel <laggardkernel@gmail.com>
https://github.com/laggardkernel/git-ignore

Generates .gitignore files offline using templates from gitignore.io

Usage:
  git-ignore 
  git-ignore keyword1 keyword2 keyword3

Example:
  git-ignore macos,linux,windows vim emacs >> ./.gitignore

Options:
  -l, --list                List available templates
  -s, --search keyword      Search template with keyword in filenames
  -u, --update              Init/Update local templates repo
  -c, --clean               Clean local gitignore templates repo
  -h, --help                Display this help screen
  -v, --version             Display version information and exit

❯ gi -l
1C,1C-Bitrix,A-Frame,Actionscript,Ada,Adobe,AdvancedInstaller,Agda,AL...
# omitted because it is too long
Total: 479

❯ gi -s py # then press <Tab> for completion
pycharm      pycharm+all  pycharm+iml  pydev        python

❯ gi -u
 Updating gitignore repo...
Already up to date.

❯ gi -c
 No available local gitignore repo
 Use `gi -u` to init

Environment Variables

: location for templates storage. It fallbacks to:

directory under plugin’s root folder
(in case the script is not used as a ZSH plugin)

Global .gitignore #

Git also allows you to create a global file, where you can define ignore rules for every Git repository on your local system.

The file can be named anything you like and stored in any location. The most common place to keep this file is the home directory. You’ll have to manually create the file and configure Git to use it.

For example, to set as the global Git ignore file, you would do the following:

Create the file:
Add the file to the Git configuration:
Open the file with your text editor and add your rules to it.

Global rules are particularly useful for ignoring particular files that you never want to commit, such as files with sensitive information or compiled executables.

Как пользоваться Git?

Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.

Обычно, структура проекта в Git будет зависеть от масштаба и сложности вашей программы. Но для начала мы будем использовать проект, состоящий только из одной ветви. Каждый проект содержит одну ветку по умолчанию, она называется master. Наш первый проект будет называться test.

Создание проекта

Когда настройка git завершена перейдем к вашему проекту. В самом начале вам достаточно создать папку для файлов проекта. Если вы собираетесь работать над несколькими проектами, создайте папку git в вашем домашнем каталоге, а уже туда поместите папки ваших проектов:

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

Перед тем как git начнет отслеживать изменения, нужно подготовить все необходимые конфигурационные файлы. Сначала инициализируем пустой репозиторий в нашей папке:

После того как репозиторий будет создан, вам нужно добавить свои файлы в него. Каждый файл нужно добавлять отдельно или сказать утилите, что необходимо добавить все файлы явно. Пока вы не добавите файл сам он не будет отслеживаться. Новые файлы в будущем тоже нужно добавлять, они не добавляются автоматически. Сначала добавим текущую папку:

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

Изменения тоже автоматически не отслеживаются. Фиксация изменений выполняется с помощью команды commit. Вам нужно указать что было изменено с помощью небольшого комментария, буквально в несколько предложений. Хорошая практика выполнять фиксацию перед каждым серьезным изменением.

Таким образом, вы будете хранить все версии проекта, от самой первой и до текущей, а также сможете знать что, когда и где было изменено. Чтобы создать свой первый коммит выполните:

Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:

Отправка изменений

До этого момента мы делали все в локальном репозитории. Вы можете использовать git локально, если нужен только контроль версий, но иногда нужно обменяться информацией с другими разработчиками и отправить данные в удаленный репозиторий.

Сначала нужно добавить удаленный репозиторий с помощью команды remote. Для этого нужно передать ей URL:

Затем можно посмотреть список удаленных репозиториев:

Вы можете использовать не только github сервера, но и любые другие. Теперь для отправки ваших изменений используйте такую команду:

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

Для простых проектов достаточно одной ветви. Но если проект большой и он имеет несколько версий, в том числе тестовую, то может понадобиться создать для каждой из них отдельную ветвь. Сначала смотрим доступные ветви:

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

Переключаться между ветвями можно тоже с помощью той же команды:

Теперь создадим еще один файл:

И добавим его в нашу новую ветвь develop:

Сделаем коммит для внесенных изменений:

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

Затем переключаемся на ветку master и снова смотрим:

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.

Global Git ignore rules

In addition, you can define global Git ignore patterns for all repositories on your local system by setting the Git property. You’ll have to create this file yourself. If you’re unsure where to put your global file, your home directory isn’t a bad choice (and makes it easy to find later). Once you’ve created the file, you’ll need to configure its location with :

You should be careful what patterns you choose to globally ignore, as different file types are relevant for different projects. Special operating system files (e.g. and ) or temporary files created by some developer tools are typical candidates for ignoring globally.

What makes a good template?

A template should contain a set of rules to help Git repositories work with a
specific programming language, framework, tool or environment.

If it’s not possible to curate a small set of useful rules for this situation,
then the template is not a good fit for this collection.

If a template is mostly a list of files installed by a particular version of
some software (e.g. a PHP framework), it could live under the
directory. See for more details.

If you have a small set of rules, or want to support a technology that is not
widely in use, and still believe this will be helpful to others, please read the
section about for more details.

Include details when opening pull request if the template is important and visible. We
may not accept it immediately, but we can promote it to the root at a later date
based on interest.

Please also understand that we can’t list every tool that ever existed.
Our aim is to curate a collection of the most common and helpful templates,
not to make sure we cover every project possible. If we choose not to
include your language, tool, or project, it’s not because it’s not awesome.

Why do I need that?

Did you know that your operating system can store a lot of hidden files in every directory you create? How about or on macOS or and on Windows? These are certainly not the files you want to commit to a Git repository.

And what about other files and directories used by various frameworks and tools? These may be for Node.js or for PHP projects using Composer. And this is only the tip of the iceberg, so you can’t possibly know every file that should be excluded from being commited to a repository.

Using this extension for Visual Studio Code you can achieve exactly that without ever leaving the editor (or even touching a mouse).

Usage

The main purpose of this extension is to generate file but it’s also smart enough to know if you already have one or if you added your custom rules to it. It’s also OS-aware so it prechecks that checkbox for you.

To use the extension go to the Command Palette ( on macOS or on Windows) and launch command.

Case 1: You don’t have .gitignore file yet

If you don’t have file already you’ll be prompted right away with the list of all available tools, frameworks etc. to choose from. You can select or deselect the item with or by clicking the checkbox. Fuzzy-search is also available to speed things up.

Once you finished press Return () and your file will be generated and saved on the disk.

Case 2: You already have .gitignore file generated by this extension

If you generated file before you’ll be asked if you want to override it entirely or just update it. If you choose former option everything goes like described in Case 1. If you choose Update, all previously chosen items will be checked automatically so you don’t have to do it again. Now you can choose other technologies or remove ones that you already have selected but don’t want to use anymore.

User-defined rules

The cool thing is that using this extension doesn’t mean that you can’t put your own exclusion rules in file for fear of loosing them when you run Update command again.

Everything you put under (at the bottom of the file) will be preserved on the next update.

Multi-folder workspace

If you have more than one folder open in the workspace you’ll be asked which one to use to generate file into or update that file from.

Contributing guidelines

We’d love for you to help us improve this project. To help us keep this collection
high quality, we request that contributions adhere to the following guidelines.

Provide a link to the application or project’s homepage. Unless it’s
extremely popular, there’s a chance the maintainers don’t know about or use
the language, framework, editor, app, or project your change applies to.
Provide links to documentation supporting the change you’re making.
Current, canonical documentation mentioning the files being ignored is best.
If documentation isn’t available to support your change, do the best you can
to explain what the files being ignored are for.
Explain why you’re making a change. Even if it seems self-evident, please
take a sentence or two to tell us why your change or addition should happen.
It’s especially helpful to articulate why this change applies to everyone
who works with the applicable technology, rather than just you or your team.
Please consider the scope of your change. If your change is specific to a
certain language or framework, then make sure the change is made to the
template for that language or framework, rather than to the template for an
editor, tool, or operating system.
Please only modify one template per pull request. This helps keep pull
requests and feedback focused on a specific project or technology.

In general, the more you can do to help us understand the change you’re making,
the more likely we’ll be to accept your contribution quickly.

Support Thread:

Josephblau
Sep 26, 11:55 CEST

This page in your documentation is causing some contention between developers and I would like clarification:

One comment in particular () has 11 up votes from the community asking for the *.iml file to be ignored, therefore not being committed to the repository, and therefore not being shared. My question is whether the documentation is correct or not?

If the documentation is correct, can you provide more details as to why the *.iml needs to be shared so I can document it on my website and also reference GitHub’s main project which also doesn’t share the *.iml?

Cheers,
Joe

Serge Baranov (IntelliJ)
Sep 26, 14:23 CEST

It would depend on the project. If the project is imported from Maven or Gradle, .iml files are generated automatically and may not be shared, otherwise these files are essential for the project and must be shared so that other users can open the project after checkout.

.iml files contain all the information about the module configuration (the roots, source folders, dependencies, etc).

Josephblau
Sep 26, 17:01 CEST

A lot of developers online seem to disagree with this assessment. There are multiple resources online which all recommending ignoring the *.iml with no negative side effects to collaborative work. Your customers seem to think that the only information held in there is Local IDE specific information which does not translate to other development environments.

Here is a response from one of the developers in project’s thread:

There are also many other comments on stack overflow related to Android Studio and IntelliJ in general:

and the list goes on…

Does IntelliJ have the ability to regenerate all of the module configuration (roots, source, dependencies, etc..) metadata?

Serge Baranov (IntelliJ)
Sep 26, 17:08 CEST

That is true only for Maven and Gradle projects as I’ve already mentioned. Android Studio projects are Gradle based, so it makes sense to ignore .iml files for AS projects.

In case the project was created in IDEA and is not Maven or Gradle based, IDEA will not be able to open it without .iml files. User will have to perform all the configuration from scratch. Basic projects can be imported and IDE will suggest source roots and libraries to add, but for the more complex multi-module projects with the dependencies between the modules configuring it from scratch for a new user would be a very hard task and a lot of manual work.

Most open source projects are using Maven or Gradle, so it makes sense to ignore .iml files and not keep them in GitHub repositories.

Pattern format

A blank line matches no files, so it can serve as a separator for readability.
A line starting with # serves as a comment. Put a backslash («\»)
in front of the first hash for patterns that begin with a hash.
Trailing spaces are ignored unless they are quoted with backslash («\»).
An optional prefix «!» which negates the pattern; any matching file excluded
by a previous pattern will become included again. It is not possible to
re-include a file if a parent directory of that file is excluded.
Git doesn’t list excluded directories for performance reasons, so
any patterns on contained files have no effect, no matter where they are
defined. Put a backslash («\») in front of the first «!» for patterns
that begin with a literal «!», for example, «\!important!.txt».
If the pattern ends with a slash, it is removed for the purpose of the
following description, but it would only find a match with a directory.
In other words, foo/ will match a directory foo and paths underneath it,
but will not match a regular file or a symbolic link foo (this is consistent
with the way how pathspec works in general in Git).
If the pattern does not contain a slash /, Git treats it as a shell glob
pattern and checks for a match against the pathname relative to the location
of the .gitignore file (relative to the toplevel of the work tree if not
from a .gitignore file).
Otherwise, Git treats the pattern as a shell glob suitable for consumption
by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will
not match a / in the pathname. For example, «Documentation/*.html» matches
«Documentation/git.html» but not «Documentation/ppc/ppc.html» or
«tools/perf/Documentation/perf.html».
A leading slash matches the beginning of the pathname. For example,
«/*.c» matches «cat-file.c» but not «mozilla-sha1/sha1.c».

Two consecutive asterisks («**») in patterns matched against full pathname
may have special meaning:

A leading «**» followed by a slash means match in all directories.
For example, «**/foo» matches file or directory «foo» anywhere, the same as
pattern «foo». «**/foo/bar» matches file or directory «bar»
anywhere that is directly under directory «foo».
A trailing «/**» matches everything inside. For example, «abc/**» matches
all files inside directory «abc», relative to the location of the
.gitignore file, with infinite depth.
A slash followed by two consecutive asterisks then a slash matches
zero or more directories. For example, «a/**/b» matches «a/b», «a/x/b»,
«a/x/y/b» and so on.
Other consecutive asterisks are considered invalid.

Examples

There are currently two useful functions in the package:

to fetch all supported gitignore
templates.
to fetch one or many gitignore templates.

Show the first 25 templates returned by .

library(gitignore)

head(gi_available_templates(), 25)
#>   "1c"                   "1c-bitrix"            "a-frame"             
#>   "actionscript"         "ada"                  "adobe"               
#>   "advancedinstaller"    "adventuregamestudio"  "agda"                
#>  "al"                   "alteraquartusii"      "altium"              
#>  "android"              "androidstudio"        "angular"             
#>  "anjuta"               "ansible"              "apachecordova"       
#>  "apachehadoop"         "appbuilder"           "appceleratortitanium"
#>  "appcode"              "appcode+all"          "appcode+iml"         
#>  "appengine"

Templates can be fetched using the function.

gi_fetch_templates("R")

# Created by https://www.gitignore.io/api/r
# Edit at https://www.gitignore.io/?templates=r

### R ###
# History files
.Rhistory
.Rapp.history

# Session Data files
.RData
.RDataTmp

# User-specific files
.Ruserdata

# Example code in package build process
*-Ex.R

# Output files from R CMD build
/*.tar.gz

# Output files from R CMD check
/*.Rcheck

# RStudio files
.Rproj.user

# produced vignettes
vignettes/*.html
vignettes/*.pdf

# OAuth2 token, see https://github.com/hadley/httr/releases/tag/v0.3
.httr-oauth

# knitr and R markdown default cache directories
*_cache
cache

# Temporary files created by R markdown
*.utf8.md
*.knit.md

### R.Bookdown Stack ###
# R package: bookdown caching files
/*_files

# End of https://www.gitignore.io/api/r

Multiple templates can be fetched by specifying multiple values:

gi_fetch_templates(c("java", "c++"))

# Created by https://www.gitignore.io/api/java,c++
# Edit at https://www.gitignore.io/?templates=java,c++

### C++ ###
# Prerequisites
*.d

# Compiled Object files
*.slo
*.lo
*.o
*.obj

# Precompiled Headers
*.gch
*.pch

# Compiled Dynamic libraries
*.so
*.dylib
*.dll

# Fortran module files
*.mod
*.smod

# Compiled Static libraries
*.lai
*.la
*.a
*.lib

# Executables
*.exe
*.out
*.app

### Java ###
# Compiled class file
*.class

# Log file
*.log

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp

# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*

# End of https://www.gitignore.io/api/java,c++

By default, templates are copied into the clipboard. It is also possible
to modify a file using the function.

f <- file.path(tempdir(), ".gitignore")
new_lines <- gi_fetch_templates("r")
gi_write_gitignore(fetched_template = new_lines, gitignore_file = f)

If is not specified, will try to find the
file of your current project or package.

More examples are provided in the vignette.

browseVignettes("gitignore")

Folder structure

We support a collection of templates, organized in this way:

the root folder contains templates in common use, to help people get started
with popular programming languages and technologies. These define a meaningful
set of rules to help get started, and ensure you are not committing
unimportant files into your repository
contains templates for various editors, tools and
operating systems that can be used in different situations. It is recommended
that you either
or merge these rules into your project-specific templates if you want to use
them permanently.
contains specialized templates for other popular
languages, tools and project, which don’t currently belong in the mainstream
templates. These should be added to your project-specific templates when you
decide to adopt the framework or tool.

Установка Git

Немного теории…

гит репозиторий (git repository);
коммит (commit);
ветка (branch);
смерджить (merge);
конфликты (conflicts);
спулить (pull);
запушить (push);
как игнорировать какие-то файлы (.gitignore).

Состояния в Гит

неотслеживаемое (untracked);
измененное (modified);
подготовленное (staged);
закомиченное (committed).

Как это понимать?

Файл, который создан и не добавлен в репозиторий, будет в состоянии untracked.
Делаем изменения в файлах, которые уже добавлены в гит репозиторий — находятся в состоянии modified.
Из тех файлов, которые мы изменили, выбираем только те (или все), которые нужны нам (например, скомпилированные классы нам не нужны), и эти классы с изменениями попадают в состояние staged.
Из заготовленных файлов из состояния staged создается коммит и переходит уже в гит репозиторий. После этого staged состояние — пустое. А вот modified еще может что-то содержать.

уникальный идентификатор коммита, по которому можно его найти;
имя автора коммита, который создал его;
дата создания коммита;
комментарий, который описывает, что было сделано во время этого коммита.

Installation

Zplugin

The only ZSH plugin manager solves the time-consuming init for
, , , , , , , etc,
with its amazing async .

zplugin ice pick'init.zsh' blockf
zplugin light laggardkernel/git-ignore
alias gi="git-ignore"

Update the plugin with

$ zplg update laggardkernel/git-ignore

Prezto

The only framework does optimizations in plugins with sophisticated coding skill:

saving startup time with
removing the horribly time-consuming from

mkdir -p ${ZDOTDIR:-$HOME}/.zprezto/contrib 2>/dev/null
git clone https://github.com/laggardkernel/git-ignore.git ${ZDOTDIR:-$HOME}/.zprezto/contrib/git-ignore

Git ignore patterns

uses globbing patterns to match against file names. You can construct your patterns using various symbols:

Pattern	Example matches	Explanation*
		You can prepend a pattern with a double asterisk to match directories anywhere in the repository.
	but not	You can also use a double asterisk to match files based on their name and the name of their parent directory.
		An asterisk is a wildcard that matches zero or more characters.
	but not	Prepending an exclamation mark to a pattern negates it. If a file matches a pattern, but also matches a negating pattern defined later in the file, it will not be ignored.
	but not	Patterns defined after a negating pattern will re-ignore any previously negated files.
	but not	Prepending a slash matches files only in the repository root.
		By default, patterns match files in any directory
	but not	A question mark matches exactly one character.
	but not	Square brackets can also be used to match a single character from a specified range.
	but not	Square brackets match a single character form the specified set.
	but not	An exclamation mark can be used to match any character except one from the specified set.
	but not	Ranges can be numeric or alphabetic.
		If you don’t append a slash, the pattern will match both files and the contents of directories with that name. In the example matches on the left, both directories and files named logs are ignored
logs/		Appending a slash indicates the pattern is a directory. The entire contents of any directory in the repository matching that name – including all of its files and subdirectories – will be ignored
		Wait a minute! Shouldn’t be negated in the example on the left Nope! Due to a performance-related quirk in Git, you can not negate a file that is ignored due to a pattern matching a directory
		A double asterisk matches zero or more directories.
	but not	Wildcards can be used in directory names as well.
	but not	Patterns specifying a file in a particular directory are relative to the repository root. (You can prepend a slash if you like, but it doesn’t do anything special.)

** these explanations assume your .gitignore file is in the top level directory of your repository, as is the convention. If your repository has multiple .gitignore files, simply mentally replace «repository root» with «directory containing the .gitignore file» (and consider unifying them, for the sanity of your team).*

In addition to these characters, you can use # to include comments in your file:

You can use \ to escape pattern characters if you have files or directories containing them:

Что мы хотим?

Получить все изменения на текущий момент в основной ветке (master, например).
На базе этой основной создать отдельную для своей работы.
Реализовать новую функциональность.
Казалось бы, зачем это делать? Это правило хорошего тона, которое предотвращает возникновение конфликтов уже после пуша своей ветки на локальный репозиторий (есть, конечно, вероятность,что все равно они будут, но она становится значительно меньше).
Запушить свои изменения на удаленный репозиторий.

Создать новую ветку на основе master

Переходим в правый нижний угол и нажимаем на Git: master, выбираем + New Branch.

Оставляем галочку Checkout branch и пишем имя новой ветки. Для меня это будет readme-improver.

После этого Git: master сменится на Git: readme-improver.

Проверить, не изменилась ли основная ветка

ctrl + treadme-improver

accept yours — принять только изменения из readme-improver.
accept theirs — принять только изменения из master.
merge — самому выбрать, что нужно оставить, а что убрать.

merge

Это изменения из readme-improver.
Результат. Пока что там так, как было до изменений.
Изменения из master ветки.

Apply

.gitignore Patterns #

is a plain text file in which each line contains a pattern for files or directories to ignore.

It uses globbing patterns to match filenames with wildcard characters. If you have files or directories containing a wildcard pattern, you can use a single backslash () to escape the character.

Lines starting with a hash mark () are comments and are ignored. Empty lines can be used to improve the readability of the file and to group related lines of patterns.

Slash

The slash symbol () represents a directory separator. The slash at the beginning of a pattern is relative to the directory where the resides.

If the pattern starts with a slash, it matches files and directories only in the repository root.

If the pattern doesn’t start with a slash, it matches files and directories in any directory or subdirectory.

If the pattern ends with a slash, it matches only directories. When a directory is ignored, all of its files and subdirectories are also ignored.

The most straightforward pattern is a literal file name without any special characters.

Pattern	Example matches

Wildcard Symbols

— The asterisk symbol matches zero or more characters.

Pattern	Example matches

— Two adjacent asterisk symbols match any file or zero or more directories. When followed by a slash (), it matches only directories.

Pattern	Example matches
	Matches anything inside the directory.

— The question mark matches any single character.

Pattern	Example matches

Square brackets

— Matches any of the characters enclosed in the square brackets. When two characters are separated by a hyphen it denotes a range of characters. The range includes all characters that are between those two characters. The ranges can be alphabetic or numeric.

If the first character following the is an exclamation mark (), then the pattern matches any character except those from the specified set.

Pattern	Example matches

Negating Patterns

A pattern that starts with an exclamation mark () negates (re-include) any file that is ignored by the previous pattern. The exception to this rule is to re-include a file if its parent directory is excluded.

Pattern	Example matches
	or will not be ignored

Клонируем проект локально

Если есть уже гитхаб аккаунт и хочется что-то потом запушить, лучше сделать форк проекта к себе и клонировать свою копию. Как сделать форк — я описывал в этой статье в главе пример the forking workflow.
Клонировать с моего репозитория и проделать все локально без возможности все это дело запушить на сервер. Ведь это же будет мой репозиторий))

Копируем адрес проекта:
Открываем Intellij IDEA и выбираем Get from Version Control:
Копируем вставляем адрес на проект:
Вам предложат создать Intellij IDEA проект. Принимаем предложение:
Так как нет системы сборки, и это не входит в задачу статьи, выбираем Create project from existing sources:
Далее будет такая картина маслом:
С клонированием разобрались, теперь-то можно и оглянуться по сторонам.