Дата | Видеоурок | Результат | |
---|---|---|---|
JD. Коллекции LIST - ArrayList против LinkedList | + 14 | ||
ArrayList - это список на основе массива. LinkedList - связанный список на основе элементов и связи между ними. В каждом узле, хранится ссылки на следующий/предыдущий узел и значение. При работе с коллекцией самые главные действие это добавление и получение элемента. В зависимости от операции и её частоты использования, решается какая коллекция будет использована. При добавление во внутрь ArrayList, приходится пересоздавать массив, копировать значения, стоящие после добавляемого элемента, на что уходит не мало времени. В LinkedList нам же просто потребуется найти место куда собираемся вставлять, и переписать ссылки, связь между элементами. В ArrayList легко можем найти нужный элемент, с одинаковой скоростью в любой части массива.(сразу прыгает на нужную ячейку). В LinkedList чтобы добраться до нужного элемента должен перебрать всю цепочку стоящую до этого элемента. |
|||
JD. Коллекции LIST - Типа коллекция | + 13 | ||
Освежил память, нашел ссылку на хорошее описание коллекций. |
|||
JD. Коллекции LIST - Просто коллекция | + 17 | ||
Последовательно добовляет объекты с даныыми Хранит именно объект, даже если забиваем обычное чило, переводит его в объект Одновременно может хранить объекты разных типов. Если пользоваться конструкцией метода add с указанием нидекс для вставки, вставляет элемент на указанный индекс, при этом двигает все элементы которые стоят после(что может быть слишком трудоемко с большими массивами, если добавить элемент в самом начале массива) сначало массив создается с размерностью 10, затем при необходимости пересоздается увеличивая каждый раз свою размерность в 1.5 раза, тоесть если добовляем 11 элемент(до этого у нас было 10), то масив пересоздастся с размерностью в 10*1,5=15 элементов и в него спокойно влезит 11 элемент. |
|||
Система Git ФИНАЛЬНЫЙ КУРС | + 18 | ||
Очень понравился курс, много позитивных мыслей, даже не страшно теперь, как говорит сам автор, лезть в теорию и что то изучать самому). Очень понравился подход "под капотом", по началу помогло понять, что мы вообще делаем, зачем это нужно, в конце же, помогло понять ценность гита, что очень много работы автоматизировано и гит реально полезен. Схема, которую обязательно нужно отпринтовать, это вообще нужная вещь!! Я её еще на середине курса, на стенку повешал, команды с ней учатся очень быстро. Получается запоминаю не совсем команды, а взаимодействия между 3 каталогами, то что мы можем и хотим с этими каталогами сделать. Было бы здорово увидеть раздел "под капотом" еще на каком нибудь из ваших курсов. Например, точно также как и гит раньше, без всякого понимания использую различные сборщики проектов, maven, ant--- для чего они нужны, как устроены, чем полезны, пока шишек не набью, точно также как с гитом, узнаю наврятли, а хотелось бы... Также хотелось бы познакомится с необходимостью тестирования, Junit. Может немного с вебом, какие нибудь фреймворки... В любом случае классный курс получился, обязательно постараюсь находить время и на другие ваши уроки. С уважением, Павел!!. |
|||
Система Git win final | + 18 | ||
Много хороших советов, повторил то что делал |
|||
Система Git remote merge | + 23 | ||
Создали отдельную ветку, в ней пингвина. таким образом спокойно можем обновить ветку мастер с сервера. После это пытаемся слить пингвина и обновленную с сервера мастер, что само собой не получается. (Файл Zoo мастера имеет создание жирафа и льва, а в ветке пингвина, заместо этого, идет создание пингвина). Можно исправить конфликт - сказать что нам нужно и то и то, но мы решили откатить слияние, и добавить ветку пингвина на сервер, отдельно, чтобы с ней мог работать другой человек, пока без объединения с мастером: git merge --abort -отменяет слияние git push origin Penguin - отправляет ветку на сервер. На гитхабе убеждаемся что у нас теперь там две ветки которые мы можем переключать. В гитбаше, с другого компа(там где нет пингвина) переходим на мастер и делаем git pull - загружает с сервера все что есть, в том числе и все ветки (в отличии от git push который загружает только указанную ветку), но другие ветки вроде(кроме мастера) не обновляет. Теперь на другом компе у нас есть ветка пингвин, разработанная вообще другим пользователем. Переходим на неё, проверяем на соответствие с мастером(получаем данные из мастера merge), устраняем конфликты, и пушим. На клоне(где создавался пингвин) переходим на ветку мастер(git pull можно только на неё делать, чтоб не изменять и не конфликтовать с другими ветками(собственно для этого они и создавались) и вроде бы как даже мы не сможем в них запулиться) и загружаем, репозиторий с сервера, уже с исправленными данными. В клоне, ветка пингвин имеет устаревшие данные (наш мастер уже имеет пингвина, и помимо этого еще и льва и жирафа) поэтому её можно удалить, ну а можно Обновить слив с мастер(git merge master) |
|||
Система Git pingwin | + 17 | ||
Делаю свои ошибки, экспериментирую. Понял, что пока не сделаю комит ветки, git status будет показывать все изменения любых веток, как будто я в этой ветке их делал. почему то git checkout не удалял файл Penguin.java. git checkout -- Penguin.java тоже. Пришлось удалить файл командой git clean -f -d - Удалить все локальные файлы и директории, которые не отслеживает Git, из вашей текущей копии. |
|||
Система Git win merge | + 17 | ||
В принципе так и представлял, из прошлого урока.... в гите более автоматизировано все, а на вине, понятней)) сложно сказать что проще... в гите надо знать все команды, понимать где ты находишься, что можешь натворить и можно ли это исправить. В вине, же все прозрачно, делаешь что хочешь, и как хочешь, любыми инструментами)) |
|||
Система Git git merge giraffe lion | + 16 | ||
Схема объеденения дочерних веток в родительскую: прежде чем объеденять нужно свою, дочернию ветку проверить на соответствие с веткой прородителем. Для этого заходим в свою ветку git checkout lion, и пытаемся слить её с прородителем git merge master (Взять из неё данные). Должно получиться так, что брать от туда нечего, нигкто туда не успел ни чего залить, ни каких хитрых изменений небыло. (только не совсем понимаю, что может произойти если не объединять сразу в master, можно ведь точно также исправить все конфликты). git merge Lion с ветки мастер, без проблем зальет в мастер льва и его вызов. Но после этого, объединения мастера с другими ветками может вызывать конфликт. git merge Giraffe (почему то) сразу нельзя заливать в master, поэтому сначало проверяем на соответствие: с жирафа получаем данные с мастера git merge master, и видим что возникает конфлик. После устранение конфликтов и комита, гит объединяет две ветки в одну (Giraffe). Нужно теперь ветку мастер поднять выше, чтобы она имела наиболее актуальные данные. Проблем быть не должно так, как конфликты мы вроде бы все устронили. После объединения, master имеет то же самое что и Giraffe, можно комитить. не совсем понимаю, что может произойти если не объединять сразу в master, можно ведь точно также исправить все конфликты |
|||
Система Git git branch giraffe | + 18 | ||
Две разные ветки, как будто два разных проекта, переключаться между ними очень легко. Интересные статья, из прошлого урока, о том как нужно создавать ветки: https://habr.com/post/106912/ |
|||
Система Git git branch lion | + 19 | ||
git branch lion - создает ветку лев(также создает новую сцену, когда мы переходим на новую ветку - git checkout lion, мы переходим на новую сцену и берем из неё данные в свою рабочую область) $ git log --graph --all --decorate --oneline --отоброзит красиво комиты. при содании ветки, нужно обращать внимание на какой ветке мы находимся в этот момент, так как мы наследуем(копируем) данные из неё. Например если мы находимя на ветке Lion и создаем ветку giraffe, то мы получаем данные из Liona, что для жирафа выглядет не очень. Должны сначало сделать git checkout master, а потом уже создавать ветку. git branch -d giraffe - удалит ветку. при смене веток: git checkout master, git checkout Lion можно наблюдать как изменяется рабочая область(меняется сцена, данные из неё вставляются в рабочую область, лишние удаляются) |
|||
Система Git hippo git fetch pull | + 18 | ||
git fetch-загружает файлы с сервера, но только в репозиторий, при этом создает свою ветку. git branch -a - отображает все ветки. remotes/origin/master - загружается проект с сервера на эту ветку, при помощи команды git fetch. git checkout remotes/origin/master - перейти на эту ветку, команда dir покажет что там есть все загруженные, командой git fetch, файлы. git checkout master - возвращаемся на главную ветку(предпологаю что это способ перемещения по веткам). git pull * |
|||
Система Git git push clone | + 19 | ||
Отправить на сервер и получить обратно наш проект Git Hub (сервер, хранилище репозиториев) сервис для работы с гитом, хранит наши проекты на удаленном сервере, в который, в любой момент, можно их загрузить(просмотреть при помощи встроенного интерфейса) git remote add origin https:////Repository name.git remote(команда обращается к удаленному серверу) origin(как называется наш удаленный сервер, принято origin) git remote(удаленный) https:////Repository name.git - где хранится, что будет, какой адрес в результате выполнения команды система запоминает метку origin. git remote rm origin - удаляет метку, если нужна другая git push -u origin master - отправляет на сервер ветку master с архивами. git clone http.../.git - загрузка с сервера проекта, с восстановлением репозитория, сцены и рабочей области. ссылка на проект находится на странице гита. если поставить точку в конце, загрузка произойдет без создания папки с именем репозитория. |
|||
Система Git git ignore | + 15 | ||
git checkout производит изменения рп со сцены. 1. если в сцене есть файл а в рп нет, произойдет добавление файла в рп. 2. если в цене нет файла а в рп есть, то из рп файл удалиться.(например сделали ресет какой либо версии из архива) 3. если в сцене есть изменения файлов, а в рп, у этих файлов изменения нет, произойдет обновление файла в рп. Если мы случайно добавили файлы на сцену, мы можем их от туда удалить 1 способ: при помощи команды cached - удаляет файл на сцене. git rm --cached Zebra.class 2 способ: git add в обратную сторону изменения сцены с рп. 1. если в сцене есть фаил а в рп нет, файл в сцене удалится. 2. если в сцене нет файла а в рп есть, файл в сцену добавиться. 3. тагже с модификацией. можно убрать модификацию в сцене(если есть изменения в сцене, а в рп их нет) и добавить её туда. .gitignore - текстовый документ в корневой папке, в котором записываются игнорируемые типы, при копировнии файлов на сцену из рп. .gitignore по аналогии похоже на батник который копирует на сцену только джава файлы copy *.java ..\stage |
|||
Система Git git commit zebra | + 19 | ||
git -a -m comit : параметр -a может за нас добавлять модифицированные файлы на сцену, во время комита. Но только модифицированные файлы, новые не может, их надо add самостоятельно. |
|||
Система Git git commit reset diff | + 16 | ||
git Status - есть ли изменения, подтверждены ли они. git dif - убидится что содержимое папок одинаковое. git dif проверяет соответствие фалов на сцене и РП git dif Hard проверяет соответствие фалов в хранилище и РП Отобразятся все различия в файлах. git log - все кoмиты, кто и когда заархивировал свои файлы комит -архвируется сцена(в которой хранятся файлы, подготовленные для этого), и помещается в хранилище, в какую либо ветку(папку), например master. При необходимости всегда сможем вернуться к этому архиву. Пример необходимости: В файле рабочей папки написали ошибку. Скопировали этот файл на сцену(подготовку к архивированию). команда git dif не находит различий между рп и сценой. git checkout не сработает(нет смысла со сцены возвращать в РП тоже самое). Но у нас есть хранилище, и в нем находится нужная нам версия файла. git dif Hard находит эти различия. выполняем git reset head - оброщаемся в архив, берем из него старую версию файлов и обновляем сцену. git dif Hard и git dif говорит что рп не соответствует ни хранилище, ни сцена. Но рп мы можем обновить со сцены командой git cheackout и работать со старой версией. |
|||
Система Git git add checkout | + 18 | ||
Созданные файлы помещаются в рабочую директорию. Гит за ними не смотрит: Untracked files(имеют красный цвет). Гит просит его добавить на сцену, чтобы можно было за ним следить. (Перед тем как архивировать файл, нужно сделать их копии). Если мы меняем файл в рабочей папке(РП)., он не соответствует файлу расположенному на сцене( готовому к архивированию). гит об этом говорит и просит, до архивирования, либо согласиться с изменениями, и обновить файл на сцене, измененным файлом в РП, либо откатить изменения, обновить файл в рабочей папке, старым файлом из сцены. |
|||
Система Git git init | + 16 | ||
есть три места которыми гит работает: где работаю, подготовка к архивированию и само хранилище. эти три места(а в целом гит-репозиторий) нужно создать командой git init, на компьютере, в том месте(папке) где мы хотим чтобы хранился наш проект. Git - это система контроля версий, а GitHub - один из множества веб-сервисов, использующих эту систему. |
|||
Система Git Добро пожаловать в Зоопарк! | + 17 | ||
Заинтересовался. |
|||
Демо софт Вступительное слово | |||
|