Как отправить изменения в репозиторий на github

Git Push – вносим изменения на GitHub

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

Кроме того, изменения, которые пользователь вносит в локальную систему, не имеют никакой ценности для участников и зрителей, если облако GitHub не отражает их.

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

Рассмотрим git push как часть процесса синхронизации в Git. Синхронизация происходит между локальным и удаленным хранилищем, где источник и приемник могут отличаться. Есть много других частей для синхронизации, и git push-это одна из частей, потому что она загружает изменения, сделанные в локальном репозитории, чтобы поддерживать удаленный репозиторий в актуальном состоянии. В этом нет ничего сложного, и концепция проста, как и ее синтаксис.

Приведенного выше изображения достаточно для понимания концепции в двух словах.

Пользователь клонирует репозиторий в качестве первого шага, чтобы внести некоторые изменения в репозиторий.

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

После завершения всех изменений пользователь затем фиксирует все изменения в локальном репозитории.

А затем передает эти изменения на удаленный сервер. Наконец, он синхронизирует локальный и удаленный репозитории.

Синтаксис команды git Push в Git

Выполнение команды git push происходит путем ввода следующей команды:

git push <remote_repo> <branch_name>

remote_repo: это имя (или псевдоним) удаленного репозитория, в который мы переносим изменения.

branch_name: это ветвь, которую пользователь толкает в удаленный репозиторий.

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

Как перенести изменения из локального репозитория в удаленный репозиторий в Git

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

Перед созданием изменений в репозитории убедитесь, что вы выполнили следующие операции:

• У вас раздвоенный репозитория на GitHub.
• Вы клонировали один и тот же репозиторий на локальную машину.

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

В качестве хорошей практики сначала проверьте, что у вас есть чистый репозиторий с помощью команды git status (никаких ожидающих изменений для фиксации).

После выполнения команды git status появятся следующие строки:

On branch master: означает, что в данный момент мы находимся в главной ветви. Поскольку других ветвей пока нет, мы по умолчанию находимся в главной ветви.

Your branch is up to date with origin/master: Origin — это имя удаленного репозитория, которое мы дали при подключении локального репозитория к удаленному репозиторию.

Последовательность действий

1. Перечислите все файлы с командой ls в репозитории.

Так как существует только один файл (README.md это всего лишь инструкция), давайте внесем некоторые изменения в его содержание.

1. Откройте файл с помощью вашего любимого редактора и внесите в него любые изменения.
2. Мы изменили файл на следующий код.

1. Добавьте внесенные изменения в промежуточную область и зафиксируйте их.

Примечание: GitHub и Git распознают любые изменения только через коммиты (commits). Если пользователь не зафиксировал изменения и пытается протолкнуть их на GitHub, он отобразит сообщение “Everything is up-to-date”

1. Введите следующую команду, чтобы перенести эти изменения в репозиторий GitHub, и нажмите клавишу enter.

git push origin master

1. Пользователь получает приглашение предоставить учетные данные с помощью GitHub в качестве части безопасности. Введите свои учетные данные и нажмите на кнопку входа в систему.

1. Как только пользователь получит одобрение и изменения объединятся, он получит следующее сообщение в Git Bash.

Примечание: последние две строки выглядят следующим образом:

https://github.com/harishrajora805/ToolsQA.git: URL-адрес репозитория, который отражает изменения.

1в4522а..285f559: показывает хэш-значение обеих ветвей. Таким образом, хэш-значение конечного коммита, отраженного на GitHub, равно 285f559.

master -> master: строка master — > master показывает исходную ветвь, из которой происходит слияние с целевой ветвью. В приведенном выше сценарии обе ветви являются главными.

Строка Writing Objects: 100% имеет важное значение. В Git можно сказать, была ли команда push выполнена успешно или нет, только взглянув на эту строку. Если она показывает 100%, то все изменения успешно перенесены в облако.

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

Варианты Git Push

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

Prune Option

— опция prune в команде git push удалит ветвь XYZ из удаленного репозитория, если в локальном репозитории не существует ветви с таким же именем.

Использование: git push –prune remote XYZ

Dry Run Option

Эта опция будет выполнять и показывать выполнение команды git push, но не будет отправлять никаких обновлений в удаленный репозиторий.

Использование: git push –dry-run <remote> <local_branch>

Atomic Option

Эта опция в git Push обеспечивает атомарную операцию на удаленном репозитории, т. е. либо каждую ссылку обновляет, либо вообще ничего.

git push –atomic <remote_repo> <working_branch>

All Option

Все опции будут выталкивать все ветви и их зафиксированные изменения в удаленный репозиторий.

Использование: git push-all <remote>

В последнем уроке мы познакомились с командой Git fetch и Read more

В одной из последних статей мы узнали о команде Git Read more

Мы уже знаем, как вносить изменения в локальное хранилище и Read more

«Клонирование» означает создание идентичных особей естественным или искусственным путем. Клонирование Read more

Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more

Все данные, доступные в локальном репозитории, могут быть загружены в Read more

Как отправить изменения в репозиторий на github

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

Git pull

Подключить новых участников к вашему репозиторию можно в меню Settings → Collaborators → Add People.

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

Сымитируем компьютер другого человека, создав вторую папку на нашем компьютере. Назовем ее «Второй участник». Открываем терминал по адресу папки, копируем ссылку на репозиторий на git hub.

Клонируем репозиторий по ссылке: git clone <ссылка на репозиторий>.

Проверим, как называется появившаяся папка с репозиторием: ls.

Заходим в нее: cd git_tutorial.

Включаем отображение веток в терминале: source

/.zchrc. Подробнее про отображение веток мы рассказывали в прошлом уроке.

Представим, что второй участник решил внести изменения. Он открыл файл в редакторе и добавил в начало кода импорт библиотеки datetime: from datetime import datetime. А последней строкой настроил вывод даты: print(«Today: «, datetime.today().strftime(‘%d/%m/%Y’))

Он коммитит изменения в терминале: git commit -a -m «Add datetime».

Заливает их на Github: git push.

Представим, что мы не знаем, что такие изменения были внесены, и продолжаем работать над проектом локально. Открываем проект в редакторе, добавляем одну строку: print(«Our project: Git_Tutorial»).

Открываем терминал по адресу нашей основной папки Git_Tutorial, в которой начинали работать над проектом. Коммитим изменения: git commit -a -m «Project name».

Пытаемся передать изменения на удаленный репозиторий: git push. Не получается. Git пишет, что версия проекта на нашем компьютере не совпадает с версией на удаленном репозитории. Так получилось, потому что другой участник проекта уже внес какие-то изменения.

Чтобы синхронизировать локальную версию с удаленной, git предлагает команду git pull. Применяем ее: git pull.

Видим сообщение о конфликте в файле test.py.

Чтобы разрешить конфликт, переходим в редактор. Зеленым подсвечены наши изменения, синим — изменения, которые добавил в проект кто-то другой.

VSCode предлагает несколько вариантов, в каком виде сохранить код. В нашей ситуации нам подходит принять все изменения. Выбираем accept both changes. Сохраняем изменения в редакторе.

Коммитим изменения в терминале: git commit -a -m «Add project name». Отправляем на GitHub: git push.

Issues

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

Создадим вкладку issue, чтобы обсуждать изменения в проекте с другими участниками. Нажимаем на зеленую кнопку, пишем название: delete input. Добавляем описание: предлагаю убрать input и переписать первую строку вывода, чтобы не вводить имя каждый раз. Здесь используется тот же язык markdown, как и в файле с описанием проекта README.

В описании можем ссылаться на конкретных людей и на конкретные коммиты, для этого нужно использовать их хэш-код. Можно сослаться и на куски кода. Зайдем в наш файл test.py и выберем строку с запросом информации с клавиатуры, который нам кажется неудобным. Нажмем на три точки рядом с выделенными строками, копируем permalink. Вставим ссылку в issue.

Посмотрим в режиме предпросмотре, как выглядит наш Issue. Если все устраивает, можем нажать submit.

Assignees — на кого назначаем вопрос. Можем выбрать любого участника проекта. В нашем проекте пока только мы, поэтому задача назначится на нас. Если вы назначили задачу на кого-то другого, он увидит уведомление об этом на своей странице Git Hub.

Label — тема нашего issue. Выберем bug. Labels можно настроить под себя.

Project и milestones — проекты и вехи. В рамках одного большого репозитория может быть несколько проектов и вех. Разные issue можно привязывать к этим вехам и проектам. Сейчас мы этот шаг пропускаем.

Pull Requests

В командной работе удобно объединять изменения не на локальном репозитории каждого участника, а на удаленном. Для этого существует функция Pull Request, то есть запрос на изменения. Работа выстраивается так: хотим добавить изменения — создаем в проекте на нашем компьютере ветку, в ветке вносим изменения, коммитим их, отправляем запрос на принятие этих изменений на сервер.

Предложенные изменения можно обсудить с другими участниками проекта в комментариях. Если с изменениями все согласны, запрос принимается.

Представим, что и мы решили исправить код, как написано в Issue. Откроем терминал. Создадим ветку для изменений del_input и перейдем в нее: git checkout -b del_input.

Перейдем в редактор и удалим input, изменим приветствие. Сохраним изменения.

Вернемся в терминал и закоммитим изменения: git commit -a -m «Delete input». Отправим изменения на сервер. Так как мы отправляем изменения не с основной ветки, обязательно прописать название удаленного репозиторий (origin) и название ветки, с которой отправляем изменения: git push -u origin del_input. Ветка с изменениями появилась на GitHub.

Внесем еще одно изменение. Вернемся в основную ветку: git checkout main. Создадим новую ветку update_test: git checkout -b update_test.

Перейдем в редактор и внесем новые изменения, сохраним их.

Вернемся в терминал и закоммитим изменения: git commit -a -m «Update test».

Отправим изменения на сервер: git push -u origin update_test.

Как только в удаленном репозитории появляется больше одной ветки, Git Hub предлагает объединить изменения из разных веток с помощью функции Pull Request.

Нажимаем compare and pull request. Base — куда мы переносим изменения, compare — откуда. Сначала заберем изменения из ветки del_input в main. Git Hub сам проверяет можно ли сделать слияние без конфликтов и помечает их галочкой. Если видим галочку, значит можно слить ветки без конфликтов.

Можем добавить какое-то описание к слиянию веток, reviewers — участники команды, которым мы даем доступ к этому pull request. Они могут просматривать его и комментировать. В Assignees можем указать, кому именно адресуем запрос на изменения.

Сейчас мы это пропустим и нажмем create pull request.

Нажав на сообщение о коммите, мы можем посмотреть, какие именно изменения предлагаются. Если у нас есть права на подтверждение pull request, мы можем слить две ветки сразу. Сольем две ветки: нажимаем merge pull request.

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

Мы можем не сливать ветки сразу, а дождаться обсуждения с другими участниками проекта. Тогда Pull request будет висеть в соответствующей вкладке.

Попробуем теперь добавить ветку update_test. Нажимаем compare and pull request.

Ветки автоматически не сливаются, возник конфликт. Все равно создаем запрос на изменения. Решить конфликт можно на странице GitHub. Нажимаем resolve conflict.

Приводим код к нужному виду. Нажимаем mark as resolved → commit merge. Теперь ветки можно слить. Все изменения добавятся в основную ветку.

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

Push existing project into Github

I have a folder with my project sources. How I can push this project into Github’s repository?

I tried using this steps:

1. I created empty repository on GitHub.
2. I run git-bash and typed git init , so inside project root appeared .git folder.
3. I added some files to version control using git add sourcesFolderName
4. I committed files added in previous step using git commit -m «initial commit»
5. I specified remote repository using git remote add MyProject <url>
6. Finally git push , but nothing is pushed to remote repo. (no authorization failure)

So how I can push existing sources into newly created github repo?

19 Answers 19

The -f option on git push forces the push. If you don’t use it, you’ll see an error like this:

In less technical terms

My answer is not different but I am adding more information because those that are new could benefit from filling in the gaps in information.

After you create the repo on github they have instructions. You can follow those. But here are some additional tips because I know how frustrating it is to get started with git.

Let’s say that you have already started your project locally. How much you have does not matter. But let’s pretend that you have a php project. Let’s say that you have the index.php, contact.php and an assets folder with images, css, and fonts. You can do it this way (easy), but there are many options:

Option 1

Login to your github account and create the repo.

In the following screen you can copy it down where you need it if you click the button (right side of screen) to "clone in desktop".

You can (or do it another way) then copy the contents from your existing project into your new repo. Using the github app, you can just commit from there using their GUI (that means that you just click the buttons in the application). Of course you enter your notes for the commit.

Option 2

• Create your repo on github as mentioned above.
• On your computer, go to your directory using the terminal. using the linux command line you would cd into the directory. From here you run the following commands to "connect" your existing project to your repo on github. (This is assuming that you created your repo on github and it is currently empty)

first do this to initialize git (version control).

then do this to add all your files to be "monitored." If you have files that you want ignored, you need to add a .gitignore but for the sake of simplicity, just use this example to learn.

Then you commit and add a note in between the "" like "first commit" etc.

Now, here is where you add your existing repo

But do not literally type <project url> , but your own project URL. How do you get that? Go to the link where your repo is on github, then copy the link. In my case, one of my repos is https://github.com/JGallardo/urbanhistorical so my resulting url for this command would just add .git after that. So here it would be

Test to see that it worked by doing

You should see what your repo is linked to.

Then you can push your changes to github

If you still get an error, you can force it with -f . But if you are working in a team environment, be careful not to force or you could create more problems.

you will need to specify which branch and which remote when pushing:

Will work as expected.

You can set this up by default by doing:

which will allow you to do a git push from master without specifying the remote or branch.

If you’re on a Mac (and this probably works the same on a PC), here’s a very easy way to do this. Strangely enough I’ve looked high and low for this simple process and never found it.

• Do not do anything on Github (other than having an account, and not having used up all your available repos).
• Download GitHub for Mac and install. Go through the account setup, etc. Do NOT create any repositories for your existing project.
• «Add New Local Repository» in repositories.
• Select your existing folder. It’ll ask if you want to do that, say yes.
• Once done, you’ll see a list of all your files, etc. Commit them.
• Go to Repositories and Publish (this will create the new repo on GitHub for you, if you set up your account properly).
• Go to Repositories and Push (you’ll either see the «nothing to push» thing, or it’ll push your files/changes to the newly-auto-made repo).
  • Wonder why you could not find this simple process anywhere else.

  I know it is not recommended to use the project folder as the repo folder. I do it all the time, it always works, it makes it simple, and I never have any trouble with it.

  I would like to share a source with you so that you learn about Git more easily.

  

  Git has been the version-control system of choice since its inception in 2005. About 87% of the developers use Git as their version-control system.

  But if you have a project that is already existing and you want to push to Git in the remote server, follow along the below steps:

  Go to the terminal of your project directory

  You need to initialize your project git using git init

  Create a .gitignore file and it is actually a text file that tells Git which files or folders to ignore in a project.

  Stage your files using git add .

  Commit your changes to your local repository with an appropriate commit message: git commit -m "my first commit"

  In this step, you just need to create a repository in any one of the distributed version control systems like GitHub or Bitbucket

  Use this Git command to link your local repository with that of the remote: git remote add <your-remote-name> <your-remote-url>

  So, if your GitHub repo-url is https://github.com/your-github-username/new-repository.git, then the Git command becomes:

  Push your code to remote GitHub repository

  git push origin master

  Note: The git push command requires two parameters: the name of the remote repository (origin) and the branch to push to (here master is the default branch for every repository).

  Refer this blog for detailed information.

  

  I will follow the previous comment from Rose P. It took me a long time to find the solution so I’m reposting (hopefully in plain English) what worked for me.

  step 1: Create your new repository on Github.com (skip if you already have one)

  step 2: Close XCode. not needed

  step 3: Open a new Terminal window (yes, you have to use terminal. I tried all other ways. nothing worked)

  step 4: Using the command cd to find your folder location to your project (the project you want to add to your existing or new repository)

  step 5: type git init you’ll get something like this. Reinitialized existing Git repository in /

  step 6: type git add . nothing happens after this step, but type it and go on to the next step.

  step 7: type git commit -m «Initial commit» you’ll get the following: # On branch master nothing to commit, working directory clean

  some explanation about configuration and then a list of files that have changed.

  Git для начинающих. Урок 6.
  git push и git pull

  Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

  Во втором уроке мы создавали репозитории на github и научились клонировать их. После этого мы работали только с локальным репозиторием, на своей машине. Сегодня мы рассмотрим взаимодействие с удаленным репозиторием.

  Что такое push (пуш)

  Это отправка данных на сервер, в удаленный репозиторий, на github. Данные — это коммиты и ветки.

  Зачем пушить на сервер

  • для работы в команде, чтобы делиться своим кодом с коллегами
  • чтобы иметь резервную копию на случай потери данных на своей машине

  Когда пушить на сервер

  Когда сделали новый коммит или несколько коммитов

  Как узнать, что есть незапушенные коммиты

  В командной строке набрать git status

  Ключевая фраза здесь «Your branch is ahead of ‘origin/master’ by 5 commits.». Это значит, что у нас есть 5 неотправленных на сервер коммитов. Если незапушенных коммитов нет, то картина будет такая

  «is up-to-date» означает, что у нас нет незапушенных коммитов

  В PhpStorm понять, есть ли неотправленные коммиты, можно посмотрев в окно Version Control — Log, где находятся метка master и origin/master. Если master выше, то есть незапушенные коммиты.

  master и origin/master

  Это ветки: локальная и удаленная (на сервере, в github). По умолчанию мы находимся в ветке master. Подробно работу с ветками мы рассмотрим в следующем уроке, а пока достаточно запомнить, что master — это то, что на нашей машине, а origin/master — в удаленном репозитории, на github.

  git push в терминале

  • push — что сделать, отправить
  • origin — куда, на сервер
  • master — что, ветку master

  Как пушить в PhpStorm

  Правый клик — Git — Repository — Push. — Кнопка Push

  Что такое pull (пулл)

  Это скачивание данных с сервера. Похоже на клонирование репозитория, но с той разницей, что скачиваются не все коммиты, а только новые.

  Зачем пулиться с сервера

  Чтобы получать изменения от ваших коллег. Или от себя самого, если работаете на разных машинах

  git pull в терминале

  • pull — что сделать, получить данные
  • origin — откуда, с сервера
  • master — а точнее, с ветки master

  Как пулить в PhpStorm

  Правый клик — Git — Repository — Pull. — Кнопка Pull

  Когда что-то пошло не так.

  Иногда при работе в команде git push и git pull могут вести себя не так, как пишут в учебниках. Рассмотрим примеры

  git push rejected

  Вы сделали новый коммит, пытаетесь запушить его, а git в ответ выдает такое

  Написано много, но суть в том, что коммит отклонен, пуш не прошел. Почему?

  Git устроен так, что локально мы можем коммитить сколько угодно. Но прежде чем отправить свои коммиты на сервер, то есть запушить, нужно подтянуть новые коммиты с сервера. Те самые, которые успели сделать наши коллеги. То есть сделать git pull.

  Когда мы делаем git push, git сначала проверяет, а нет ли на сервере новых коммитов. Если они есть, то git выдает то самое сообщение — git push rejected. Значит, нам нужно сначала сделать git pull, а затем снова запушить

  Здесь нас подстерегает неожиданность — в терминале выскакивает окно редактирования коммита. Пока просто сохраним, что предложено по умолчанию и закроем редактор. Вот теперь можно пушить свои коммиты

  Все, наши коммиты на сервере. При этом появится странный коммит «Merge branch ‘master’ of github.com:Webdevkin/site-git». Это так называемый мердж-коммит, о нем чуть ниже.

  Если же при попытке пуша новых коммитов на сервере нет, то git push пройдет сразу и отправит наши коммиты на сервер.

  Как избавиться от мердж-коммита

  Мердж-коммит появляется, когда вы сделали локальный коммит, а после этого подтянули новые коммиты с сервера. Мердж-коммит не несет смысловой информации, кроме самого факта мерджа. Без него история коммитов выглядит чище.

  Чтобы избавиться от него, подтягивайте изменения командой git pull с флажком —rebase

  При этом ваш локальный коммит окажется «поверх» нового коммита с сервера, а мердж-коммита не будет. И не забудьте после этого запушить свой коммит на сервер.

  Мердж-коммит в PhpStorm

  PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий. Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант: как подтянуть новые коммиты, с мерждем или ребейзом. Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.

  Что могу посоветовать

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

  Но при работе в команде имеет смысл подумать над такими вещами:

  • пушить коммиты почаще, чтобы коллеги быстрее получали доступ к новым изменениям
  • пулиться почаще — обратная ситуация, почаще получать свежие изменения
  • всегда пультесь с флажком ребейза — git pull —rebase origin master
  • не удивляйтесь, что при пуллах и пушах могут возникать подобные ситуации, как мы рассматривали выше
  • не стесняйтесь спрашивать коллег, если увидели незнакомую ситуацию
  • больше практикуйтесь. Посадите домашний проект на git и работайте с ним

  Не переживайте, если иногда будете чувствовать себя, как друзья ниже. Это нормально, новый инструмент не осваивается за 5 минут. Немного практики, и мы будем понимать, почему иногда git ведет себя не так, как хочется, и главное, будем понимать, как это исправить.

  

  В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними. Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.

  Похожие публикации:

  1. Как обрезать фото на компьютере windows 10
  2. Как скомпилировать с в linux
  3. Как скопировать текст в мэш ссылку
  4. Почему компьютер не видит фотоаппарат canon через usb