Upload files in GitHub using Git Bash Terminal (Creating Basic Repository and Adding Files)
As we all know, GitHub is a wonderful platform where you can share, discover and build various software. So in this blog, I will be discussing in detail about creating a basic repository and adding files in the repository.
Pre-requisitions before using Git Bash Terminal
Before you use Git Bash, make sure you have your GitHub account so that you can create your repository there then upload and view your files. In case you…
Как загрузить папку в git
The git add command adds new or changed files in your working directory to the Git staging area.
git add is an important command — without it, no git commit would ever do anything. Sometimes, git add can have a reputation for being an unnecessary step in development. But in reality, git add is an important and powerful tool. git add allows you to shape history without changing how you work.
When do you use git add ?
As you’re working, you change and save a file, or multiple files. Then, before you commit, you must git add . This step allows you to choose what you are going to commit. Commits should be logical, atomic units of change — but not everyone works that way. Maybe you are making changes to files that aren’t logical or atomic units of change. git add allows you to systematically shape your commits and your history anyway.
What Does Git Add Do?
git add [filename] selects that file, and moves it to the staging area, marking it for inclusion in the next commit. You can select all files, a directory, specific files, or even specific parts of a file for staging and commit.
This means if you git add a deleted file the deletion is staged for commit. The language of «add» when you’re actually «deleting» can be confusing. If you think or use git stage in place of git add , the reality of what is happening may be more clear.
git add and git commit go together hand in hand. They don’t work when they aren’t used together. And, they both work best when used thinking of their joint functionality.
How to Use git add
Common usages and options for git add
- git add <path> : Stage a specific directory or file
- git add . : Stage all files (that are not listed in the .gitignore ) in the entire repository
- git add -p : Interactively stage hunks of changes
You can see all of the many options with git add in git-scm’s documentation.
Examples of git add
git add usually fits into the workflow in the following steps:
- Create a branch: git branch update-readme
- Checkout to that branch: git checkout update-readme
- Change a file or files
- Save the file or files
- Add the files or segments of code that should be included in the next commit: git add README.md
- Commit the changes: git commit -m «update the README to include links to contributing guide»
- Push the changes to the remote branch: git push -u origin update-readme
But, git add could also be used like:
- Create a branch: git branch update-readme
- Checkout to that branch: git checkout update-readme
- Change a file or files
- Save the file or files
- Add only one file, or one part of the changed file: git add README.md
- Commit the first set of changes: git commit -m «update the README to include links to contributing guide»
- Add another file, or another part of the changed file: git add CONTRIBUTING.md
- Commit the second set of changes: git commit -m «create the contributing guide»
- (Repeat as necessary)
- Push the changes to the remote branch: git push -u origin update-readme
git add All Files
Staging all available files is a popular, though risky, operation. This can save time, but the risks are two-fold:
Poorly thought out history
By staging all available changes, the clarity of your history will likely suffer. Being able to shape your history is one of the greatest advantages of using Git. If your commits are too large, contain unrelated changes, or are unclearly described in the commit message, you will lose the benefits of viewing and changing history.
Accidentally staging and committing files
By using an option to add all files at once, you may accidentally stage and commit a file. Most common flags don’t add files tracked in the .gitignore file. But, any file not listed in the .gitignore file will be staged and committed. This applies to large binary files, and files containing sensitive information like passwords or authentication tokens.
Deciding to stage all files
If the time is right to stage all files, there are several commands that you can choose from. As always, it’s very important to know what you are staging and committing.
- git add -A : stages all files, including new, modified, and deleted files, including files in the current directory and in higher directories that still belong to the same git repository
- git add . : adds the entire directory recursively, including files whose names begin with a dot
- git add -u : stages modified and deleted files only, NOT new files
git add A Folder or Specific File
The safest and clearest way to use git add is by designating the specific file or directory to be staged. The syntax for this could look like:
git add directory/ : Stage all changes to all files within a directory titled directory
git add README.md : Stage all changes within the README.md file
Undo Added Files
Before undoing a git add , you should first be sure that you won’t lose any work. There’s no way to «revert» an add in the same way you can revert a commit, but you can move the files out of the staging area.
For example, if you have a staged file, and then you make more changes to that file in your working directory. Now, the versions in your working directory and your staging area are different. If you take action to remove the changed version of the file from the staging area, the changes that were in your working directory but not staged will be overwritten.
To avoid this, first stage all changes, then unstage them together, or commit the changes and reset back before the commit happened.
Using git reset to undo git add
git reset is a flexible and powerful command. One of its many use cases is to move changes out of the staging area. To do this, use the «mixed» level of reset, which is the default.
To move staged changes from the staging area to the working directory without affecting committed history, first make sure that you don’t have any additional changes to the files in question as mentioned above. Then, type git reset HEAD (aka git reset —mixed HEAD ).
- git status : Always a good idea, this command shows you what branch you’re on, what files are in the working or staging directory, and any other important information.
- git checkout [branch-name] : Switches to the specified branch and updates the working directory.
- git commit -m «descriptive message» : Records file snapshots permanently in version history.
- git push : Uploads all local branch commits to the remote.
Get started with git and GitHub
Review code, manage projects, and build software alongside 40 million developers.
Git и Github. Простые рецепты
При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это Git и сервис Github.
Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.
Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.
После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.
В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.
Создание локального репозитория
Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.
Для просмотра папки удобно воспользоваться командой tree, которая покажет не только содержимое каждой папки, но и древовидную структуру директорий.
Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc
Переходим в папку с проектом /home/user/project:
И показываем список файлов с расширением .pyc:
Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:
Очень рекомендуется не спешить и сразу ключ этот не добавлять. Первый раз вызвать команду для просмотра файлов и только убедившись, что в список не попало ничего полезного добавить ключ удаления.
Создадим локальный репозиторий в папке с проектом:
После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.
Добавление файлов в локальный репозиторий
Для добавления файлов используется команда:
После выполнения команды, файл readme будет добавлен в систему управления версий (конечно если он уже был то этого в проекте). При добавлении файла генерируется хеш значение, которое выглядит примерно так:
Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:
Что легко увидеть с помощью команды:
Сам файл является архивом, который легко распаковать и вывести на экран, указав полное значение хеша.
Для того, чтобы добавить все файлы из текущей директории введите:
Если нужно добавить файлы из текущей директории и из всех поддиректориев, то используйте:
Для того, чтобы в систему не попадали временные файлы, можно их занести в файл .gitignore, который нужно создать самостоятельно и разместить в корневом каталоге проекта (на том же уровне, что и .git директория).
Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.
После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).
Для просмотра текущего состояния можно воспользоваться командой:
После выполнения команды мы увидим, что в stage area находится наш файл:
Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.
Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.
Можно отменить добавления файла readme в staging area с помощью команды:
После выполнения команды, файл readme отметится, как неизмененный системой.
Создание версии проекта
После того, как мы добавили нужные файлы в staging area мы можем создать версию проекта. С помощью команды:
Каждая новая версия сопровождается комментарием.
После коммита, мы сможем найти два новых объекта внутри .git репозитория.
Посмотрим, что внутри:
Ключ -t показывает тип объекта. В результате мы видим:
Для второго объекта:
Для самого первого файла:
Если мы будем дальше изучать содержимое этих файлов, то обнаружим древовидную структуру. От каждого коммита можно по ссылкам пройти по всем измененным файлам. Для практического применения это не очень нужно, но возможно так будет легче понять, что происходит при работе с системой Git.
Самую первую версию отменить нельзя. Ее можно только исправить. Если вы хотите добавить изменения в последнюю версию, то после выполнения команды commit, добавляете необходимые изменения и вызываете:
Ключ —no-edit нужен, чтобы не вводить заново комментарий.
Можно просмотреть изменения, которые вы внесли последним коммитом:
Ключ —name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.
Если вы продолжили работать и изменили только те файлы, которые были уже добавлены в систему командой git add, вы можете сделать коммит одной командой:
Для просмотра списка всех коммитов, воспользуйтесь командой:
Ключ —oneline нужен, чтобы уменьшить количество информации выдаваемой на экран. С этим ключем каждый коммит показывается в одну строчку. Например:
Для того, чтобы просмотреть изменения по конкретному коммиту, достаточно в команду git show добавить хеш значение коммита, которое можно получить с помощью предыдущей команды.
Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:
Для того чтобы удалить все файлы в папке, которые не относятся к проекту и не сохранены в репозитории, можно воспользоваться командой:
Создание репозитория на Github
До текущего момента мы работали с локальным репозиторием, который сохранялся в папке на компьютере. Если мы хотим иметь возможность сохранения проекта в интернете, создадим репозиторий на Github. Для начала нужно зарегистрироваться на сайте github.com под именем myuser (в вашем случае это может быть любое другое имя).
После регистрации нажимаем кнопочку «+» и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.
В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.
Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).
Можем просмотреть результат добавления с помощью команды:
Если все было правильно сделано, то увидим:
Для того, чтобы отменить регистрацию удаленного репозитария введите:
Это может понадобиться, если вы захотите поменять SSH доступ на HTTPS. После этого можно добавить его опять, например под именем github и протоколом HTTPS.
Следующей командой вы занесете все изменения, которые были сделаны в локальном репозитории на Github.
Ключ -u используется для того, чтобы установить связь между удаленным репозиторием github и вашей веткой master. Все дальнейшие изменения вы можете переносить на удаленный репозиторий упрощенной командой.
Перенос репозитория на другой компьютер
После того, как репозиторий был создан на Github, его можно скопировать на любой другой компьютер. Для этого применяется команда:
Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).
Так же можно добавить название папки, в которой вы хотите разместить локальный репозиторий.
Работа с одним репозиторием с разных компьютеров
С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.
Для получения обновлений с удаленного репозитория воспользуйтесь командой:
Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:
Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.
Как мы уже знаем, для того чтобы изменения выложить на удаленный репозиторий используется команда:
В случае, если в удаленном репозитории лежат файлы с версией более новой, чем у вас в локальном, то команда git push выдаст ошибку. Если вы уверены, что хотите перезаписать файлы в удаленном репозитории несмотря на конфликт версий, то воспользуйтесь командой:
Иногда возникает необходимость отложить ваши текущие изменения и поработать над файлами, которые находятся в удаленном репозитории. Для этого отложите текущие изменения командой:
После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой:
Русские Блоги
Как загрузить папку на GitHub через Git под Windows?
Чтобы написать код на компьютере через систему Windows, вам необходимо загрузить проект на GitHub. Например, при написании бэкэнда Django на Pycharm весь проект находится в форме папки, так как же эту папку можно загрузить на GitHub с помощью команд Git?
Подробные шаги приведены ниже:
1. Сначала установите клиент git.
Способ установки очень простой, как и при установке QQ, войдите на официальный сайт:https://git-scm.com/Щелкните справа, чтобы загрузить версию пакета программного обеспечения для Windows, а затем дважды щелкните, чтобы установить его, шаг за шагом.
После завершения установки вы можете увидеть следующее в стартовом меню, даже если она прошла успешно:
На этом этапе щелкните правой кнопкой мыши любую папку, и вы увидите Git Bash Here , Щелкните, чтобы войти в командное окно, как показано ниже.
2. Создайте соответствующий склад на GitHub.
Конечно, при этом предполагается, что у вас должна быть учетная запись на веб-сайте GitHub. Если нет, вам нужно зарегистрировать ее. Регистрация очень удобна, не доставляет особых хлопот.
Я беру в качестве примера проект MxShop, который изучаю, склад устроен следующим образом:
Здесь мы выбираем Public и проверяем README, что является описанием проекта. Затем нажмите кнопку создания в левом нижнем углу, что очень просто.
3. Загрузите папку под windows
Затем мы возвращаемся в командное окно git bash.Поскольку мы щелкнули папку правой кнопкой мыши, чтобы открыть ее, мы нашли каталог папки. в состоянии пройти pwd Команда для просмотра расположения папки:
Затем превратите папку в хранилище, которым может управлять Git:
Мы можем просмотреть содержимое папки с помощью команды ls:
Тогда пройдите git add Отправьте все файлы в промежуточную область:
Поскольку это первая подача, необходимо подавать все документы. Если подавать по одному слишком сложно, пройдите . К заказу можно подать все документы.
А потом, git commit -m ‘Описание’ Просто отправьте его в репозиторий.
Таким образом, мы создали склад локально, а затем нам нужно связать локальный склад со складом на веб-сайте GitHub.
Следующий URL-адрес — это местоположение склада, который мы только что создали на веб-сайте GitHub, который можно скопировать с веб-сайта следующим образом:
После связывания локального склада со складом на веб-сайте GitHub вы можете нажать, но когда вы нажимаете в первый раз, следует отметить, что склад на веб-сайте GitHub не пустой. Мы создали его, когда создавали его. A README, поэтому вам нужно их объединить.
Наконец, просто нажмите.
Этот параметр с -u означает отправку всего содержимого основной ветки. После первой связи вы можете отправить его снова без этого параметра. После каждого изменения вы можете только отправить свое изменение. Достаточно.
Вернитесь на сайт GitHub и обновите наш склад MxShop2, вы увидите, что все содержимое папок в Windows было синхронизировано.
4. Регулярное обслуживание
После завершения первой загрузки все последующие изменения, внесенные локально, можно синхронизировать с помощью следующих команд.
5. Общие команды git
mkdir: XX (создать пустой каталог XX относится к имени каталога)
pwd: отобразить путь к текущему каталогу.
git init превращает текущий каталог в управляемый репозиторий git и генерирует скрытые файлы .git.
git add XX добавляет файл xx во временное хранилище.
git commit -m "XX" Отправка файлов -m сопровождается комментариями.
git status Просмотр статуса склада
git diff XX Просмотр содержимого измененного файла XX
git журнал просмотреть историю
git reset —hard HEAD ^ или git reset —hard HEAD
вернуться к предыдущей версии
cat XX Просмотр содержимого файла XX
git reflog просмотреть идентификатор номера версии записи истории
git checkout — XX отменить все изменения файла XX в рабочей области.
git rm XX удалить файл XX
git remote add origin https://github.com/zongyunqingfeng/testgit связать удаленную библиотеку
git push —u (вам нужно использовать -u в первый раз, он вам не понадобится позже) origin master отправляет текущую главную ветку в удаленную библиотеку
git clone https://github.com/zongyunqingfeng/testgit clone из удаленного репозитория
git checkout —b dev Создать ветку dev и переключиться на ветку dev
git branch просмотреть все текущие ветки
git checkout master переключиться обратно на главную ветку
git merge dev объединяет ветку dev в текущую ветку
git branch —d dev удалить ветку dev
git имя ветки создать ветку
git stash скрывает текущую работу и продолжает работать после восстановления сцены позже
git stash list Просмотр списка всех скрытых файлов
git stash apply восстанавливает скрытые файлы, но содержимое не удаляется
git stash drop удалить файлы
git stash pop удаляет файлы при восстановлении файлов
git удаленный просмотр информации об удаленной библиотеке
git remote -v Просмотр подробной информации об удаленной библиотеке
git push origin master Git отправит основную ветку в удаленную ветку, соответствующую удаленной библиотеке