- Git — работаем с удаленным репозиторием на GitHub | Инструменты android разработчика
- Как работать с файлом .gitignore:
- Основные правила синтаксиса файла .gitignore:
- Пример файла .gitignore:
- How to Create and Manage Your First Git Repository
- Contents
- Git Repository: Main Tips
- The Basics of Repository
- How to Access Git Repository
- How to Initialize Git Repository
- What is a GIT Repository?
- Working Area or Staging of a Git Repository
- Working with a Repository
- Adding to a Repository
- Synchronizing with Remote Repositories
Git — работаем с удаленным репозиторием на GitHub | Инструменты android разработчика
- как создать репозиторий на GitHub
- как загрузить код проекта в удаленный репозиторий на GitHub
- как расшарить доступ к удаленному репозиторию на гитхабе для совместной работы над проектом
- как клонировать удаленный репозиторий
- как работать с файлом .gitignore (на этой странице под видео)
- работаем с Git через консоль Windows.
Как работать с файлом .gitignore:
Основные правила синтаксиса файла .gitignore:
- Одна строчка — одно правило,
- Пустые строки игнорируются,
- Комментарии доступны через решётку(#) в начале строки,
- Символ «/» в начале строки указывает, что правило применяется только к файлам и папкам, которые располагаются в той же папке, что и сам файл .gitignore,
- Доступно использовать спецсимволы: звёздочка(*) заменяет любое количество символов(ноль или больше), вопросик(?) заменяет от нуля до одного символа. Можно размещать в любом месте правила,
- Две звёздочки(**) используются для указания любого количества поддиректорий, подробнее смотри ниже в примерах,
- Восклицательный знак(!) в начале строки означает инвертирование правила, необходим для указания исключений из правил игнорирования,
- Символ «\» используется для экранирования спецсимволов, например, чтобы игнорировать файл с именем «!readme!.txt«, нужно написать такое правило: «\!readme!.txt«,
- Для игнорирования всей директории, правило должно оканчиваться на слэш(/), в противном случае правило считается именем файла.
Пример файла .gitignore:
- # Игнор-лист файлов проекта
- # Игнорировать ВСЕ файлы и директории, включая поддиректории и файлы в них
- *
- # —- ФАЙЛЫ —-
- # Игнорирование по типу файла, будут игнорироваться в АБСОЛЮТНО всех директориях
- # Например /files/data.zip, /server.log, /uploads/users/data/info.xls
- *.zip
- *.log
- *.pdf
- *.xls
- # Игнорирование файла во ВСЕХ директориях
- # Например /params/db/config.php, /config.php
- config.php
- # Игнорирование конкретного файла ТОЛЬКО в корне проекта
- # (корнём считается расположение файла .gitignore)
- # Например НЕ БУДЕТ проигнорирован файл /db/config.php
- /config.php
- # Игнорирование конкретного файла ТОЛЬКО в указанной директории
- # Например НЕ БУДЕТ проигнорирован файл /prod/params/config.php
- /params/config.php
- # —- ДИРЕКТОРИИ —-
- # Игнорирование всех файлов и папок ТОЛЬКО в конкретной директории(включая поддиректории и файлы в них)
- # Например /images/user.jpg, /images/company/logo.png
- # НЕ БУДУТ проигнорированы файлы и папки /prod/images/user.jpg
- /images/*
- # Игнорирование всех файлов и папок в ЛЮБЫХ директориях с указанным именем
- # Например /images/user.jpg, /core/images/user.jpg
- images/*
- # Игнорирование ВСЕХ html-файлов в ОДНОЙ КОНКРЕТНОЙ директории(НЕ ВКЛЮЧАЯ поддиректории)
- # Например /private/index.html
- # НЕ БУДУТ проигнорированы файлы в /private/ivan/index.html
- /private/*.html
- # Игнорирование ВСЕХ html-файлов в КОНКРЕТНОЙ директории ВКЛЮЧАЯ поддиректории
- # Например /private/info.html, /private/users/ivan/info.html
- /private/**/*.html
- # —- РАЗНОЕ —-
- # Исключение из игнорирования
- # Игнорирование ВСЕХ файлов и папок внутри директории /secret,
- # за исключением файла /secret/free.txt, он не будет проигнорирован
- /secret/*
- !/secret/free.txt
- # Игнорирование файла с именем, содержащим спецсимволы
- # Например !readme!.txt
- \!readme!.txt
- # Игнорирование всех JPG и JPEG файлов внутри директорий,
- # которые начинаются на «h» и МОГУТ содержать ещё один символ после
- # Например /images/h4/user.jpg, /images/h/company.jpeg
- /images/h?/*.jp?g
Ссылки:
Скачать установщик Git: тут
Шпаргалка по командам Git: тут
Туториал по Git: тут
Основы работы с редактором VIM: тут
Больше уроков:
Уроки по android разработке: ссылка
Дизайн android приложений: ссылка
Уроки создания игр для android: ссылка
Основы программирования на JAVA: ссылка
Источник
How to Create and Manage Your First Git Repository
Wherever you work, whether on your local computer or cloud, the files and changes must be saved somewhere. That is the reason why Git repository is one of the basic and most popular functions to use. Git repository, just like the name indicates, serves as a storage for all the changes and files that relate to a certain project. That is the shortest answer to the question of what is a repository.
Initializing Git repository is quite simple. However, if you want to learn how to work with Git repository properly, you must understand how and why files are stored there. Some Git repositories can be local, placed directly at your local computer. You can use an already existing directory as a repository for your Git files or create a brand new one.
If you work in a team or you are invited to make changes to a particular code, chances are you will need to access a remote Git repository. Git clone command or Git clone repository are the names for a command that create a local version for you of that remote Git repository so that you could create your own changes without any damage to the remote version.
In this tutorial, you will be explained how to clone a Git repository and how to initiate one from the very beginning.
Keep reading below!
Contents
Git Repository: Main Tips
- Git has a place called repository, sometimes shorten as repo, where your Git projects are stored.
- All changes in a project and versions of savedfiles are in its repository.
- Git clone command is used to create an identical copy of remote Git repository, but it can also be placed locally, on developer’s computer .
The Basics of Repository
What is a repository? To put it simply, it is a place where all the files of a certain project are placed. It can be both, either a remote storage space or a locally accessible directory. For instance, storage space in the cloud, an online host or local folder on your computer all can serve as repositories. In this particular folder, sometimes also abbreviated as a repo, Git saves all the files and project-related information, such as changes history.
There are two types of repositories — local and remote. Correspondingly, there are two options to work with Git: to start an entirely new project or join an already existing one.
How to Access Git Repository
One of the easiest ways to get a Git repository is to use a local directory. It must be free, i.e., not yet used for a version control system work.
Most of the work with Git is done locally. However, it is important to keep in mind that none of the files are tracked until a user asks Git to start doing so — that will make the files version-controlled. Initialising a repository is exactly a way to ask Git to enable version control on the files held in that repository.
How to Initialize Git Repository
To begin with Git repository, you have to go to the project’s that you intend to control directory. Here you have to run ‘git init’ command. This process is called initializing a repository.
This command creates a new Git repository. In general, it is used to initialize an empty new repository or convert an existing unversioned project into a Git repo.
You need a folder in which you will hold all the files of your project. One way to do it is simply manually. First of all, choose a location where you want to create a folder. In this example you can see how the «Git lessons» folder is created on the desktop:
That is done by typing this command into a new terminal window:
$ cd Desktop/Git lessons/
$ git init
Another way to do the same is by right-clicking your mouse, opening a Git bash and typing Git init.
You should see a message similar to this one with Git lesson folder created on Desktop:
Initialized empty Git repository in . /Desktop/Git lessons/.git/
Источник
What is a GIT Repository?
Repositories in GIT contain a collection of files of various different versions of a Project. These files are imported from the repository into the local server of the user for further updations and modifications in the content of the file. A VCS or the Version Control System is used to create these versions and store them in a specific place termed as a repository. The process of copying the content from an existing Git Repository with the help of various Git Tools is termed as cloning. Once the cloning process is done, the user gets the complete repository on his local machine. Git by default assumes the work to be done on the repository is as a user, once the cloning is done.
Users can also create a new repository or delete an existing repository. To delete a repository, the simpler way is to just delete the folder containing the repository.
Repositories can be divided into two types based on the usage on a server. These are:
- Bare Repositories: These repositories are used to share the changes that are done by different developers. A user is not allowed to modify this repository or create a new version for this repository based on the modifications done.
- Non-bare Repositories: Non-bare repositories are user-friendly and hence allow the user to create new modifications of files and also create new versions for the repositories. Cloning process by default creates a non-bare repository if any parameter is not specified during the clone operation.
Working Area or Staging of a Git Repository
A working tree in a Git Repository is the collection of files which are originated form a certain version of the repository. It helps in tracking the changes done by a specific user on one version of the repository. Whenever an operation is committed by the user, Git will look only for the files which are present in the working area, and not all the modified files. Only the files which are present in the working area are considered for commit operation.
The user of the working tree gets to change the files by modifying existing files and removing or creating files.
There are a few stages of a file in the working tree of a repository:
- Untracked: In this stage, the Git repository is unable to track the file, which means that the file is never staged nor it is committed.
- Tracked: When the Git repository tracks a file, which means the file is committed but is not staged in the working directory.
- Staged: In this stage, the file is ready to be committed and is placed in the staging area waiting for the next commit.
- Modified/Dirty: When the changes are made to the file i.e. the file is modified but the change is not yet staged.
After the changes are done in the working area, the user can either update these changes in the GIT repository or revert the changes.
Working with a Repository
A GIT repository allows performing various operations on it to create different versions of a project. These operations include the addition of files, creating new repositories, committing an action, deleting a repository, etc. These modifications will result in the creation of different versions of a project.
Adding to a Repository
After performing various modifications on a file in the Working Area, GIT needs to follow two more steps to save these changes in the local repository.
These steps are:
- Adding the changes to the Index(Staging Area)
- Committing the indexed changes into the repository
Adding changes to the Index
This process is done by the use of git add command. When the changes have been made in the Working Tree/Area. These changes need to be added to the Staging Area for further modification of the file. git add command adds the file in the local repository. This stages them for the commit process.
Syntax:
Different ways to use add command:
To add a specific list of files to staging area.
To add all files of current directory to staging area.
To add all text files of the current directory to staging area.
To add all text files of a particular directory(docs) to staging area.
To add all files in a particular directory(docs) to staging area.
To add text files of entire project to staging area.
Committing changes from the Index
Committing process is done in the staging area on the files which are added to the Index after git add command is executed. This committing process is done by the use of git commit command. This command commits the staged changes to the local repository.
Syntax:
This commit command is used to add any of the tracked files to staging area and commit them by providing a message to remember.
Synchronizing with Remote Repositories
Git allows the users to perform operations on the Repositories by cloning them on the local machine. This will result in the creation of various different copies of the project. These copies are stored on the local machine and hence, the users will not be able to sync their changes with other developers. To overcome this problem, Git allows performing syncing of these local repositories with the remote repositories.
This synchronization can be done by the use of two commands in the Git. These commands are:
- push
- pull
Push: This command is used to push all the commits of the current repository to the tracked remote repository. This command can be used to push your repository to multiple repositories at once.
Syntax:
To push all the contents of our local repository that belong to the master branch to the server(Global repository).
Pull: Pull command is used to fetch the commits from a remote repository and stores them in the remote branches. There might be a case when other users perform changes on their copy of repositories and upload them with other remote repositories. But in that case, your copy of the repository will become out of date. Hence, to re-synchronize your copy of the repository with the remote repository, the user has to just use the git pull command to fetch the content of the remote repository.
Syntax:
Источник