Stage & Commit Files: git add, git commit, & git log
Git Tips & Commands
Related Resources
Learn more about Git
Think of Git as keeping a list of changes to files. So how do we tell Git to record our changes? Each recorded change to a file (or set of files) is called a commit. Read to learn more.
Staging
Before we make a commit, we must tell Git what files we want to commit (new untracked files, modified files, or deleted files). This is called staging and uses the add command. Why must we do this? Why can’t we just commit something directly? Let’s say you’re working on two files, but only one of them is ready to commit. You don’t want to be forced to commit both files, just the one that’s ready. That’s where Git’s add command comes in. We add files to a staging area, and then we commit what has been staged. Even the deletion of a file must be tracked in Git’s history, so deleted files must also be staged and then committed.
Check Status
Let’s first check the status of our Git repo.
1. In your terminal (Terminal, Git Bash, or Windows Command Prompt), navigate to the folder that is your Git repo.
2. Enter this command:
git status
3. You’ll see what branch you are on (which for new repos will be master) and status of files (untracked, modified, or deleted). We’ll explain branches later.
Stage Files to Prepare for Commit
1. Enter one of the following commands, depending on what you want to do:
2. Check the status again by entering the following command:
git status
3. You should see there are changes ready to be committed.
Unstage a File
If you accidental stage something, use the following command to unstage it:
git reset HEAD example.html
(replace example.html with your file or folder)
Deleting Files
If you delete files they will appear in git status as deleted, and you must use git add to stage them. Another way to do this is using git rm command, which both deletes a file and stages it all with one command:
Commit Files
1. Enter this command:
TIP: For commit messages do you not use past tense, such as «I made headings blue». Use language like «Make headings blue», as if you are giving orders to the codebase. One reason for this is when you work with other people, your code may not be automatically approved. You’ll request that they pull your changes into the codebase. When they read the commit messages they will do know what your code will do. Your change will «Make headings blue».
2. Check the status again by running this command:
git status
3. If all changes have been committed, and there are no untracked files, it should say: nothing to commit, working tree clean.
Fixing Your Last Commit Message
If you made a mistake in your last commit message, run this command:
View a List of Commits
When viewing a list of commits, there are various commands depending on how much info you want to see.
NOTE: If the list is long, use the Down/Up Arrow keys to scroll and hit Q to quit.
NOTE: If the list is long, use the Down/Up Arrow keys to scroll and hit Q to quit.
Go Beyond Git
We offer a full suite of coding courses for students of all levels. Learn through real-world projects from expert instructors. Check out our coding bootcamps and classes now:
Related Resources
What is Git and Why Should You Use it?
From web developers to app developers, Git is useful to anyone who writes code or track changes to files. So what’s it all about and why should you start using it?
How to Create a Git Repository: git init
A Git repository (or repo for short) contains all of the project les and the entire revision history. Learn the Git command to make a repository.
Git Command Line Basics
While there is a lot you can do via the command line interface, the main thing you need to know how to do for Git is to navigate to a folder.
Продвинутые функции гита, о которых вы, возможно, не знали
Git – очень мощный инструмент, который практически каждый разработчик должен использовать ежедневно, но для большинства из нас git сводится к нескольким командам: pull commit push. Однако, чтобы быть эффективным, продуктивным и обладать всей мощью git, необходимо знать ещё несколько команд и трюков. Итак, в этой статье мы исследуем функции git, которые просто запомнить, применять и настроить, но которые могут сделать ваше время с git гораздо более приятным.
Прокачиваем базовый рабочий процесс
Прежде чем мы воспользуемся даже самыми базовыми командами – pull, commit и push, необходимо выяснить, что происходит с нашими ветками и изменёнными файлами. Для этого можно воспользоваться git log – довольно известной командой, хотя не все знают, как сделать его вывод на самом деле читабельным и красивым:
git log для функции.
Команда открывает редактор, в котором отображается один «hunk» [кусок], представляющий собой кусок кода с несколькими отличающимися друг от друга строками в нём. Можно много чего сделать с этим куском, но самые важные опции – это y – принять изменения (делает стейджинг), n – не принимать (не делать стейджинг) и e – отредактировать кусок перед стейджингом (полный список опций здесь).
Исправление распространённых ошибок
Поменьше грубой силы
Правильное слияние веток
Если вы работаете над репозиторием, в котором участвует более одного разработчика, можно с уверенностью предположить, что вы работаете в отдельной ветке, а не в мастере. Это также означает, что рано или поздно вам придётся включить свой код в кодовую базу (главную ветку). Вполне вероятно, что, пока вы работали над своей веткой, кто-то другой уже добавил свой код в мастер, из-за чего ветка вашей функциональности отстаёт на несколько коммитов. Можно пойти напролом и выполнить слияние вашего кода в мастер с помощью git merge, но команда создаст дополнительный коммит слияния, а также, без необходимости на то, затруднит чтение истории и сделает её сложнее:
История с ветвлением.
Приём выше позволяет нам повторно применять последние 4 коммита и изменить их, получив полезный результат, например сжать одни коммиты и переформулировать другие:
Выше показан пример сеанса rebase. В верхней части показывается ветка перед перезагрузкой. Вторая часть фрагмента – это список коммитов, представленных после запуска git rebase … каждый из них можно выбрать, чтобы включить в работу (pick). Мы можем изменить действие для каждого из них, а также полностью переупорядочить коммиты. Как показано в третьем разделе примера, некоторые допустимые действия – переформулирование (оно говорит git открыть редактор сообщений о коммите), сжатие коммита (объединяет коммиты в предыдущий) и исправление коммита: (исправление работает как сжатие, но при этом сбрасывает сообщение о коммите). После того как мы применим эти изменения и переформулируем изменённые коммиты, мы получим историю, которая показана на скриншоте выше, в его нижней части.
Если всё это кажется слишком сложным или вы просто боитесь работать с rebase, в качестве альтернативы создайте пул реквест на GitHub и нажмите кнопку Rebase and merge, чтобы сделать, по крайней мере, простые и быстрые rebase и merge с быстрой перемоткой.
Главное – эффективность
Я думаю, что примеры выше показали несколько изящных советов и хитростей, но всё это может быть довольно сложно запомнить, особенно когда дело касается команд вроде git log. К счастью, чтобы разрешить эти трудности, можно воспользоваться глобальной конфигурацией git. Она находится в
Выше приведён пример некоторых из доступных опций конфигурации. Примечательно, что длинная команда git log – это только псевдоним git graph. Автокоррекция установлена 10: такое значение включает её и заставляет ждать 1 секунду, прежде чем выполнить правильную команду, в которой была опечатка, и, наконец, последний раздел – подписывание коммита GPG (подробнее об этом читайте ниже).
Автозавершение команд – это инструмент не менее продуктивный, чем псевдонимы, и он просто устанавливается:
Extras
Можно не только писать свои псевдонимы, но и взять на вооружение плагин git-extras, он вводит много полезных команд, которые могут немного упростить вам жизнь. Я не буду вдаваться в подробности обо всех возможностях этого плагина – посмотрите список команд, а я просто покажу один краткий пример из этого списка прямо здесь:
git delta – список файлов, которые в другой ветке отличаются.
git show-tree – древовидное представление коммитов всех ветвей, похожее на показанный ранее git log.
git pull-request – пул-реквест в командной строке.
git changelog – генерирует журнал изменений (changelog) из тегов и сообщений в коммитах.
Конечно, это не единственный крутой плагин. Например, есть ещё один удобный инструмент, позволяющий открыть репозиторий в браузере прямо из командной строки. Кроме того, в приглашении терминала можно настроить статус репозитория, это делается с помощью zsh или bash-it.
Подписываем коммиты
Даже если вы никогда не вкладывались в какой-либо проект Open Source, вы, вероятно, прокручивали историю коммитов такого проекта. В ней вы, скорее всего, видели значок подтверждённого (sign-off – знак о правах на ПО), проверенного или подписанного коммита. Что это такое и зачем?
Первый значок используется, когда автор подтверждает, что соответствующий код написал именно он, или же значком вы подтверждаете, что, насколько вам известно, он был создан на основе соответствующей лицензии Open Source. Это делается по юридическим причинам, которые связаны со статусом авторских прав на код. Обычно вам не нужно пользоваться этим значком, но, если вы в какой-то момент захотите внести вклад в проект, который требует подтверждения прав, знак подтверждения ставится так:
Что касается значка signed/verified, который вы, вероятно, заметили в некоторых репозиториях, он существует, потому что на GitHub довольно легко выдавать себя за других пользователей. Всё, что вам нужно сделать, – изменить имя сделавшего коммит человека и электронную почту в вашей конфигурации и отправить изменения. Чтобы предупредить ситуацию, вы можете подписывать коммиты с помощью ключей GPG, подтверждающих, что автор коммита и отправитель изменений на самом деле является тем, за кого он себя выдаёт. Подпись коммита более распространена, чем подтверждение прав, поскольку важно знать, кто на самом деле внёс код.
Если вы хотите начать пользоваться этой функцией или, возможно, хотите внедрить её в вашей команде, можно сделать следующее:
Подписанный непроверенный коммит.
Затем скопируйте этот ключ и вставите его в поле https://github.com/settings/gpg/new. Если вы проверите ранее подписанный коммит после добавления ключа, то увидите, что коммит теперь проверен (verified). Здесь предполагаем, что вы добавили на GitHub именно тот ключ, которым подписывали коммит:
Подписанный проверенный коммит.
Заключение
Узнайте подробности, как получить Level Up по навыкам и зарплате или востребованную профессию с нуля, пройдя онлайн-курсы SkillFactory со скидкой 40% и промокодом HABR, который даст еще +10% скидки на обучение.
Командная работа в Git
Во всем множестве статей по git’у, которые я смог найти в сети, не хватает одного существенного момента — описания командной работы. То, что обычно описывают как командную работу, на самом деле является просто работой с удаленным репозиторием.
Ниже я хочу описать свой опыт командной работы над проектом с использованием git’а.
1. Общий принцип
Рабочий процесс у меня организован следующим образом.
Я ведущий разработчик тире руководитель отдела тире проджект менеджер. У меня в команде есть несколько разработчиков.
Моя работа заключается в следующем:
1) поговорить с заказчиком
2) превратить смутное и путанное пожелание заказчика в четко сформулированную задачу
3) поставить эту задачу разработчику
4) проверить результат выполнения задачи разработчиком
5) неудовлетворительный результат вернуть разработчику на доработку
6) удовлетворительный результат представить заказчику на утверждение или сразу отправить в продакшн
7) утвержденный заказчиком результат отправить в продакшн
8) неутвержденный заказчиком результат вернуть разработчику на доработку
Работа разработчика, соответственно, заключается в следующем:
1) получить от меня задачу
2) выполнить ее
3) отправить мне результат
4) если задача вернулась на доработку — доработать и снова отправить мне
Для управления задачами я использую Trac. Так же в Trac’е ведется документация по проекту, как программерская, так и пользовательская.
Сформулировав задачу, я записываю ее в Trac и назначаю какому-то разработчику. Разработчик, выполнив задачу, переназначает ее мне. Я проверяю результат и, либо снова переназначаю ее разработчику, либо отмечаю как выполненную.
Алгоритм работы с git’ом и общая картина происходящего схематически представлены на картинке:
Теперь от теоретической части перейдем к практической и разберемся, что все это значит и как работает.
2. Git
Установите Git. Прочитайте какой-нибудь мануал. Разберитесь с локальным репозиторием.
Обратите внимание — эта статья не про команды git’а, а про то, как увязать эти команды в нужную последовательность. Поэтому далее я буду приводить команды git’а без подробных объяснений, предполагая, что назначение отдельных команд вам известно.
3. Доступ к репозиторию
При командной работе потребуется обеспечить доступ к репозиторию нескольким пользователям. Для удобного разруливания прав доступа к репозиторию я использую gitosis.
Gitosis — это набор скриптов, реализующих удобное управление git-репозиториями и доступом к ним. Работает это так:
— на сервере заводится пользователь, которому будут принадлежать все репозитории
— все обращения к репозиториям происходят по SSH, под именем этого пользователя, авторизация пользователей производится по ключам
— при входе по SSH автоматически запускаются скрипты gitosis, которые, в зависимости от настройки, разрешают или запрещают дальнейшие действия с репозиториями
Скрипты и конфиги gitosis сами хранятся в репозитории и настраиваются путем отправки коммитов в этот репозиторий. Звучит безумно, но на деле ничего особо хитрого, вполне просто и удобно.
4. Установка gitosis
Для установки gitosis’а нужно (сюрприз!) вытянуть установочный репозиторий gitosis’а с сервера разработчика gitosis’а:
$ git clone git://eagain.net/gitosis.git
$ cd gitosis
$ su
# python setup.py install
Установочный репозиторий больше не понадобится, его можно удалить.
Теперь нужно создать в системе пользователя, которому будут принадлежать все репозитории:
$ su
# adduser gituser
А затем инициализировать gitosis в домашнем каталоге созданного пользователя, с открытым ключом того, кто будет администратором gitosis’а. Открытый ключ, понятно, нужно положить куда-то, откуда его сможет прочитать пользователь gituser:
Difference between stash vs stage files in GIT
When I need to save my changes from one branch before checking out to another branch, git sometimes says: stage or commit the files before you can checkout to another branch. But I have been recommended to use stash option so:
Stage the files is not enough to save my files before checking out to another branch?
What are the differences between stage and stash files?
1 Answer 1
1.- More than «save» your files, is act as Git expect to according their flow. (Advice, Git knows 🙂 )
2.- Stash will move your modified files into a stack. So, later in the same or in another branch, you will be able to bring them back and see those modifications in your project.
Stage is the step before to make a commit, you add modified files to «Staged files» to create your next commit.
Now, you stash your files with
and you add files (stage) with
Now, why is better stash your changes than staging them? Maybe this part of the documentation can solve your doubts: From documentation:
Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the git stash command.
Git для новичков (часть 2)
В прошлой статье, я рассказал, что такое Git, как его установить и выложить свой код на GitHub. Сегодня мы поговорим про работу в команде над одним проектом. И как это устроено в Git.
В данной статье, вся работа с Git будет через командную строку.
Совместная работа
Для того, чтобы создать новую ветку вводим:
Эти команды делают тоже самое, только второй вариант позволяет сразу переключиться в новую ветку. Вносить изменения в новую ветку можно сразу после ее создания.
При создании новой ветки, старайтесь называть ее кратким и ёмким именем. Чтобы сразу было понятно, что именно изменялось по проекту. Если вы используете, какую-нибудь систему для ведения задач, то можете в начале названия ветки указывать ID задачи, чтобы можно было легко найти, на основе какой задачи была создана ветка. Например вот так:
В каждом новом commit следует оставлять коммент и в нем описывать суть изменений.
Переключаться между ветками можно такой командой:
Для того чтобы посмотреть текущее состояние ветки, например, какие файлы добавлены или не добавлены для создания commit, можно выполнить команду:
Теперь все ваши изменения, в ветке master улетели в GitHub. Таким же образом, можно отправить любую другую ветку:
?Совет. Каждый коммит, лучше заливать сразу в удаленный репозиторий. Никто не застрахован, поломки собственного ПК. Поэтому чтобы не потерять все наработки, не забывайте сливать ваши изменения на GitHub.
Как же теперь другой человек получит все ваши изменения?
Для этого вам понадобиться GitHub или любой другой сервис для хранения кода. В прошлой статье я рассказывал как отправить код в GitHub. Сейчас я покажу, как его скопировать обратно себе на компьютер.
Если у вашего друга раньше не было проекта, то ему придется его «клонировать» себе:
? Адрес репозитория на GitHub можно получить, нажав на зеленую кнопку Code
После выполнения команды, в папке где появиться проект и ваш друг сможет с ним работать. Все ветки и их история также подтянуться.
Теперь самое главное
Перед тем, как создавать новый функционал и новую ветку, стоит обновить master на вашем устройстве. Для этого нужно находиться в этой ветке и выполнить следующую команду:
Таким же образом можно актуализировать любую другую ветку, заменив название ветки master на вашу.
Для обновления всех веток сразу, можно использовать такую, команду, но не рекомендую:
Теперь можно создавать новую ветку и кодить.
Какие проблемы могут возникнуть?
Git старается автоматически сливать изменения, однако это не всегда возможно. Иногда возникают конфликты. Например, когда в двух ветках были изменения в одной и той же строчке кода. Если такое произошло, то необходимо разрешить конфликт вручную. Для этого откройте файл там, где этого произошло. Например, вы можете увидеть что-то подобное:
После внесения нужных изменений добавьте ваш файл через git add как измененный и создайте новый commit:
Вспомогательные команды
Просмотреть изменения относительно двух веток можно командой:
Удалить ненужную ветку:
Просмотр историю ветки:
Подсказки по популярным командам:
Практика и вспомогательные инструменты
Для улучшения ваших навыков, в очередной раз оставлю ссылку на полезный тренажер с заданиями.
Так же, для удобства использования в Visual Studio Code, советую поставить это расширение, которое визуализирует ваши ветки и commit, и помогает с ними работать.
