Запись изменений в репозиторий
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Отслеживание новых файлов
Индексация изменённых файлов
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Сокращенный вывод статуса
Игнорирование файлов
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Просмотр индексированных и неиндексированных изменений
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
Коммит изменений
Эта команда откроет выбранный вами текстовый редактор.
В редакторе будет отображён следующий текст (это пример окна Vim):
Вы можете видеть, что комментарий по умолчанию для коммита содержит закомментированный результат работы команды git status и ещё одну пустую строку сверху. Вы можете удалить эти комментарии и набрать своё сообщение или же оставить их для напоминания о том, что вы фиксируете.
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
github changes not staged for commit
I have a very basic github setup with a readme, a directory, and another directory inside it with an html file. On github I can only view the readme and the first folder but none of its contents, and I am getting this message
I feel like if I am adding all to be staged that it should not be an issue. Any help?
13 Answers 13
This recurses into sub-directories, whereas I don’t think * does.
WARNING! THIS WILL DELETE THE ENTIRE GIT HISTORY FOR YOUR SUBMODULE. ONLY DO THIS IF YOU CREATED THE SUBMODULE BY ACCIDENT. CERTAINLY NOT WHAT YOU WANT TO DO IN MOST CASES.
I think you have to go inside week1 folder and delete the .git folder:
then go back to top level folder and do:
then do a commit and push the code.
in my case, I needed a
the ‘a’ on the commit was needed.
Is week1 a submodule?
Note the relevant part from the output of the git status command:
(commit or discard the untracked or modified content in submodules)
Try cd week1 and issuing another git status to see what changes you have made to the week1 submodule.
See http://git-scm.com/book/en/Git-Tools-Submodules for more information about how submodules work in Git.
WARNING! THIS WILL DELETE THE ENTIRE GIT HISTORY FOR YOUR SUBMODULE. ONLY DO THIS IF YOU CREATED THE SUBMODULE BY ACCIDENT. CERTAINLY NOT WHAT YOU WANT TO DO IN MOST CASES.
I was having the same problem. I ended up going into the subdirectory that was «not staged for commit» and adding, committing and pushing from there. after that, went up one level to master directory and was able to push correctly.
This command may solve the problem :
All the files and subdirectories will be added to be tracked.
From there you can cd out and push to whichever branch you want.
In my case the problem was the subfolder that I was tying to push was a git folder itself
So I did the following
I kept receiving the same message no matter what i did.
If you are the same, do this.
So, the problem is, git thinks some of your subdirectory is sub-project in your root-project. At least, in my case it wasn’t like that. It was just regular sub-directory. Not individual project.
Move that regular sub-directory which is not being pushed at some temporary location.
cd to the root directory.
We will have to force it as the git will see the conflict between remote git and your local structure. Remember, we created this conflict. So, don’t worry about forcing it.
Now, it will push that sub-directory as sub-directory and not as sub-module or sub-project inside your root-project.
Git changes not staged for commit Explanation
Before you create a commit, you have to add the files you have changed to that commit. When you run the git status command before adding files to a commit, you’ll see the changes not staged for commit message in the output of the command.
- Career Karma matches you with top tech bootcamps Get exclusive scholarships and prep courses
- Career Karma matches you with top tech bootcamps Get exclusive scholarships and prep courses
In this guide, we’re going to discuss what this message means and why it is important. We’ll walk through an example of how you can stage the files you need to add to a commit.
changes not staged for commit
Files in a Git repository can either be ignored, in the staging area, or part of a commit.
Ignored files are not included in the record of a Git repository. Files in the staging area are those that are going to be added to the next commit.
The staging area is important because it lets you choose which files should and should not be added to a commit. You can add or remove files from the staging area at any time before you create a commit.
This means the staging area is somewhat of a triage space. If you realize an additional file needs to be added into a commit, you can add it to staging. Then, once you are sure you have added all the changes to the staging area, you can create a commit.
An Example Scenario
To receive this message, we must first change a file in a Git repository. Suppose we have a Git repository with a blank file called README.md. We’re going to change its contents to show the following:
81% of participants stated they felt more confident about their tech job prospects after attending a bootcamp. Get matched to a bootcamp today.
Find Your Bootcamp Match
The average bootcamp grad spent less than six months in career transition, from starting a bootcamp to finding their first job.
Start your career switch today
We have changed a file in our repository. Next, we’re going to run the git status command to view a summary of all the files that have changed:
Let’s see what this command displays:
Your branch is up to date with ‘origin/master’.
Changes not staged for commit:
The Git command line tells us we are viewing the master branch and our current branch is up to date with our remote branch. We have changed one file: README.md. This file has not yet been added to the staging area or a commit. Our working directory is modified.
- Career Karma matches you with top tech bootcamps Get exclusive scholarships and prep courses
To make this message go away, we have to add the README.md file to the staging area. We can do this using the git add command:
This command lets us selectively choose files to add into a commit. Next, we can create a commit with the files we have changed that are currently in the staging area. Let’s run git commit to create a commit:
This will create a record of the current state of the repository with all of the changes we’ve added to the staging area. If you are working with a repository with a remote version, you may want to push your commit to the repository after making it:
Our change has now been made to both the local and remote versions of our repository.
Let’s take a look at the git status on branch again again:
The command tells us there are no changes that have not been added to a commit or the staging area. This means we have successfully changed our repository. There is now one additional commit in our repository which contains the change we made to README.md.
Conclusion
The “changes not staged for commit” message shows when you run the “git status” command and have a file that has been changed but has not yet been added to the staging area.
This is not an error message, rather a notification that you have changed files that are not in the staging area or a commit. You can make the message go away by adding your files to a commit and committing them to a repository.
Now you have the knowledge you need to fix this Git error like a professional developer!
«Career Karma entered my life when I needed it most and quickly helped me match with a bootcamp. Two months after graduating, I found my dream job that aligned with my values and goals in life!»
Подробное руководство по Git
Основные сообщения в консоли:
Снимки состояний как основа
Большинство систем хранят информацию как список изменений, связанных с файлами (Subversion).
GIT же делает снимок файлов в конкретный момент времени и сохраняется ссылка на этот снимок. Для увелечения эффективности на неизмененные файлы делается ссылка на их раннее сохраненные версии.
Контрольная сумма
3 состояния для файлов
Файлы в GIT могут находиться в 3 состояниях:
Как строится процесс работы в Git
Настройки
Данную информацию следует указать обязательно, так как она будет включаться во все ваши коммиты:
Узнаем подробности о том, как работает команда, например, log :
Пример файла .git/config
Псевдонимы (алиасы) в GIT
Команда git config позволяет создавать псевдонимы:
.gitignore
Игнорируем имена файлов:
Звезда означает фрагмент в имени:
Указываем диапозон (для игнорирования файлов):
Игнорируем от корня проекта:
При этом данные конструкции работают одинаково:
** используются, чтобы обозначить произвольное количество фрагментов пути:
! используется, когда требуется игнорировать все кроме чего-либо конкретного:
Жизненный цикл состояния файлов
Основные команды в Git
git init
Чтобы проинициализировать (создать) пустой Git репозиторий введите команду:
git clone
Получаем копию существующего репозитория, клонировав удаленный, например, с gitHub.
Эта команда аналогично предыдущей, но все файлы перемещаются в папку [name_folder]
git status
Команда, показывающая статус репозитория, чтобы увидеть в каком состоянии находится наш проект:
git add (Отслеживание новых файлов)
Данная команда может работать как «Добавление файлов к проекту» (добавляем в индекс).
Чтобы сообщить git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью команды:
git add (Индексация изменённых файлов)
Также данная команда может работать как «Добавление содержимого к следующему коммиту».
Давайте модифицируем файл, уже находящийся под версионным контролем. Чтобы проиндексировать его, необходимо выполнить команду:
git reset (Отмена индексирования)
Примечательно, что команда git status покажет, как отменить индексирование:
git commit
При каждой фиксации мы сохраняем снимок проекта, к которому можно вернуться в любой момент, или чтобы сравнить с текущим состоянием.
git rm
Чтобы удалить директорию:
git amend (Изменение последнего коммита)
Если вы что-то не сделали в последнем коммите, то отредактировать его не сложно. Все, что нужно это добавить изменения в индекс обычным образом:
Эта команда берет индексированный файлы и включает в коммит всю обнаруженную там информацию.
Чтобы изменить название коммита выполните:
git checkout (Отмена изменение в файле)
С подсказкой опять поможет команда git status :
Итак, файлы могут быть возвращены в состояние последнего коммита с помощью команды:
git checkout (Получаем предыдущие версии файлов, не трогая остальные)
Допустим нам нужно вернуть версию файла, которая была два коммита назад. При этом нам требуется откатить лишь один файл.
Восстановим файл index.html на момент конкретного коммита ( 0b335 ):
Или откатим версию файла до состояния из текущего коммита (откатим изменения, которые нас не устраивают):
git clone
Очистка проекта от всех изменений (git clean)
Команда git clean предназначена для удаления только неотслеживаемых файлов и директорий
Просмотр (diff)
Команда git diff используется для сравнения коммитов или файлов.
Сравниваем с текущим состоянием
Покажем изменения в рабочей директории с момента последнего коммита:
Но при этом обе приведенные выше команды игнорируют неотслеживаемые файлы.
Ограничим сравнение по пути:
Сравним состояние 2-х коммитов
Сравним состояние 2-х веток
сравним, что сделано в feature по сравнению с веткой master :
Сравниваем файлы из разных коммитов
Сравнение по словам
Чтобы включить отличия по словам:
Удаленный репозиторий
git remote (прсматриваем уд. реп.)
Команда git remote позволяет просмотреть удаленные репозитории
git remote add (добавляем уд. реп., для работы локально)
Добавление удаленных репозиториев под коротким именем:
— теперь вместо полного URL-адреса в командную строку можно вводить имя alias_repo
В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку master :
git fetch (Извлечение данных из уд. реп.)
Извлечение данных из удаленного репозитория выполняется командой:
После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта.
git push (проталкиваем изменения на уд. сервер)
Отправляем изменения в удаленный репозиторий:
Отправим ветку master на удаленный репозиторий master :
Или, что тоже самое:
Отправим ветку master на удаленный репозиторий masterB :
git push (удаляем удаленные ветки)
Удаляем ветку в удаленном репозитории:
git pull (скачиваем изменения)
git remote show (получаем инфо. об уд. реп.)
Удаленные ветки
Если вам потребуется своя локальная ветка ( name_branch ), аналогичная удаленной ветки, то можно воспользоваться командой:
Или создадим локальную ветку, чье имя будет отличаться от имени удаленной ветки:
Текущая ветка начнет следить за удаленной origin/test-git
Чтобы увидеть актуальные ветки наблюдения:
Ветвление
Ветки в Git всего лишь указатели на предыдущие коммиты, перед каждым коммитом указатель автоматически сдвигается вперед.
git branch (создаем ветку)
При создании новой ветки создается новый указатель, который, как отмечалось выше, автоматически сдвигается вперед (при каждом коммите).
Указатель HEAD указывает на текущую локальную ветку.
Узнаем указатели веток:
Обратите внимание. Узнаем указатели веток, историю коммитов, точки расхождения:
git branch (управление ветками)
Отобразим все ветки:
* указывает на ветку с указатедем HEAD(текущая).
Отобразим ветку с информацией о коммите:
Ветки слитые с текущей:
Ветки не слитые с текущей:
git checkout (смена веток)
Перейдем в существующую ветку:
Создадим и сразу перейдем в нее:
Переносим коммиты в другую ветку или Передвигаем (Откатываем) коммиты
Создадим ветку ( feature ) от текущей:
Теперь нам нужно передвинуть master на то количество коммитов, которое нам необходимо.
Или, пусть master указывает туда же куда и new_f :
Создадим ветку master на указанном коммите и переключимся на нее:
git merge
Объединяем текущую локальную ветку с удаленной:
Создаем новую ветку на основе изменений в другой ветке
Бывают ситуации, когда вы начинаете работать на какой-либо ветке, но изменения становится настолько большими, что вам хотелось бы перенести их в новую ветку. Это сделать довольно просто:
—ours к файлу
Допустим, после merge ветки feature в master в файле index.html появились конфликты, при этом мы уверены, что код на ветке master правильный. Чтобы разрешить конфликты в этом случае нам поможет команда:
—theirs к файлу
Если нам нужно взять версию из сливаемой ( feature ) ветки:
—merge к файлу
Вернуться к версии с маркерами конфликта:
Отменяем слияние и сбрасываем конфликты
reflog
Для адекватного вывода reflog используют команду, например, для ветки master :
Или без аргументов выведет reflog для HEAD :
Зачем нужен reflog:
Восстановим ветку по коммиту (под windows потребуются »):
Выводим reflog с датой:
2. Переходим на предыдущую ветку, с которой был checkout на текущую ветку:
Как работает: по reflog ищет ближайший checkout на текущую ветку.
git stash (сохраняем изменения)
Иногда возникает ситуация, когда вы работаете на одной ветке и вам срочно нужно переключиться на другую ветку, при этом регистрировать изменения нежелательно.
Для таких случае существует команда stash. Команда stash собирает незакоммиченные изменения, удаляет их из файлов и в специальном виде архивирует в Git.
git stash pop
Восстановить(вернуть) изменения поможет следующая команда:
Ошибки при git stash
Иногда мы можем сделать git stash pop не на той ветке, где сохранили изменения, это может привести к ошибке.
Просмотр истории и старых версий
git log
Для просмотра изменений (истории коммитов) используется команда
, которая покажет список последних коммитов и их хеши SHA1. Первыми показываются последние коммиты.
Или можно использовать
Или для конкретной ветки
У git log множество возможностей, например, мы можем выводить историю в более удобном формате:
Ограничивать коммиты по времени:
Показывать разницу, внесенную каждым коммитом:
Выведем коммиты достижимые из всех ссылок:
Просмотр коммитов (кроме)
Просмотр коммитов (И различий) по файлу
Выведем коммиты, в которых менялся файл index.html :
Выведем конкретные различия, в которых менялся файл index.html :
Флаги-фильтры для log (поиск изменений в файлах)
Поиск всех коммитов в описании которых есть слово word :
Найдем вызов функции:
Найдем объявление функции:
Не забывайте, что function doAny\( это регулярное выражение.
Выводи все коммиты с n-й по n-ю строку, например, выведем с 3-й по 7-ю строку:
Или найдем фрагмент кода по регулярному выражению:
Возможность очень полезная, так как позволяет отследить изменения любого блока кода в файле.
git show
git show используется для того чтобы проанализировать коммит, по хэшу:
git show (Смотрим на коммит родителя/предыдущий)
смотрит на 2 коммита вниз (
Тоже самое можно указать через число:
Как посмотреть на файл в предыдущем коммите
Флаг HEAD можно заменить @ :
Посмотрим на файл index.html в ветке master :
Смотрим на текущую (проиндексированную) версию файла
Ищем коммит по описанию (слову)
Кто написал эту строку? git blame
Вывести информацию о том, кто написал каждую строку в package.json:
Сократим дату и выведем только те строки, которые нас интересуют (например, с 5-й по 8-ю):
git reset
Как вернуть коммит, убранный reset
Подведем итог: мягкий reset отменяет коммит, но оставляет все подготовленные для коммита данные.
Передвигает ветку, сбрасывает индекс, но не трогает рабочую директорию. То есть изменения останутся в рабочей директории, но не будут проиндексированы. Пример использования:
reset переносит ветку, но так как HEAD указывает на текущий коммит, то ветка переносится туда же, где и сейчас, то есть ничего не происходит. Однако есть второй полезный момент: сброс индекса на состояние соответствующего коммита ( HEAD ), сами изменени останутся в рабочей директории, то есть очистка от всех изменений.
Для замены коммита запускаем:
Конфликты в Git
Команда git status позволяет увидеть файлы с конфликтами.
cherry-pick
Команда cherry-pick используется, чтобы переместить какой-либо коммит (по хешу) из одной ветки в другую.
Например, поместим коммит 268510c2f в ветку master (текущая).
rebase
Перенос веток
Отказ от переноса
Чтобы отказаться от переноса (например, ваш rebase остановился на конфликте) выполните команду:
Чтобы пропустить коммит при переносе, например, rebase остановился на конфликте, вы можете выполнить команду:
Отмена rebase
Отмена rebase после того как rebase завершился.
Или (что более надежно).
Работаем с bitbucket.org
1. кликаем по this repository Fork
3. создадим ветку (на основе удаленной ветки test-git )
4. и внесем в нее какие-либо изменения
5. Фиксация изменений
6. Отправка новой ветки в ветку на bitbucket
Далее переходи на bitbucket
7. Находим нужную ветку и делаем Create pull request (запрос на включение): где вы можете выбрать как проекты, так и ветки куда пойдет запрос на слияние.
Владелец проекта может выделить часть кода и написать к нему комментарий. Как только это произойдет пользователь, открывший запрос на включение получит уведомление. Пользователь вносит правки и отправляет его.
8. Принимаем pull request
Полезные приемы
Как в git заменить ветку master полностью другой веткой?
Я имею две ветки в моем репо:
2. seotweaks (создана от master )
