Как обновить проект с github

Как обновить проект с github

git pull updates your current local working branch, and all of the remote tracking branches. It’s a good idea to run git pull regularly on the branches you are working on locally.

Without git pull , (or the effect of it,) your local branch wouldn’t have any of the updates that are present on the remote.

What Does git pull Do?

git pull is one of the 4 remote operations within Git. Without running git pull , your local repository will never be updated with changes from the remote. git pull should be used every day you interact with a repository with a remote, at the minimum. That’s why git pull is one of the most used Git commands.

git pull and git fetch

git pull , a combination of git fetch + git merge , updates some parts of your local repository with changes from the remote repository. To understand what is and isn’t affected by git pull , you need to first understand the concept of remote tracking branches. When you clone a repository, you clone one working branch, main , and all of the remote tracking branches. git fetch updates the remote tracking branches. git merge will update your current branch with any new commits on the remote tracking branch.

git pull is the most common way to update your repository.

However, you may want to use git fetch instead. One reason to do this may be that you expect conflicts. Conflicts can occur in this way if you have new local commits, and new commits on the remote. Just like a merge conflict that would happen between two different branches, these two different lines of history could contain changes to the same parts of the same file. If you first operate git fetch , the merge won’t be initiated, and you won’t be prompted to solve the conflict. This gives you the flexibility to resolve the conflict later without the need of network connectivity.

Another reason you may want to run git fetch is to update to all remote tracking branches before losing network connectivity. If you run git fetch , and then later try to run git pull without any network connectivity, the git fetch portion of the git pull operation will fail.

If you do use git fetch instead of git pull , make sure you remember to git merge . Merging the remote tracking branch into your own branch ensures you will be working with any updates or changes.

How to Use git pull

Common usages and options for git pull

• git pull : Update your local working branch with commits from the remote, and update all remote tracking branches.
• git pull —rebase : Update your local working branch with commits from the remote, but rewrite history so any local commits occur after all new commits coming from the remote, avoiding a merge commit.
• git pull —force : This option allows you to force a fetch of a specific remote tracking branch when using the <refspec> option that would otherwise not be fetched due to conflicts. To force Git to overwrite your current branch to match the remote tracking branch, read below about using git reset .
• git pull —all : Fetch all remotes — this is handy if you are working on a fork or in another use case with multiple remotes.

You can see all of the many options with git pull in git-scm’s documentation.

Examples of git pull

Working on a Branch

If you’re already working on a branch, it is a good idea to run git pull before starting work and introducing new commits. Even if you take a small break from development, there’s a chance that one of your collaborators has made changes to your branch. This change could even come from updating your branch with new changes from main .

It is always a good idea to run git status — especially before git pull . Changes that are not committed can be overwritten during a git pull . Or, they can block the git merge portion of the git pull from executing. If you have files that are changed, but not committed, and the changes on the remote also change those same parts of the same file, Git must make a choice. Since they are not committed changes, there is no possibility for a merge conflict. Git will either overwrite the changes in your working or staging directories, or the merge will not complete, and you will not be able to include any of the updates from the remote.

If this happens, use git status to identify what changes are causing the problem. Either delete or commit those changes, then git pull or git merge again.

Keep main up to date

Keeping the main branch up to date is generally a good idea.

For example, let’s say you have cloned a repository. After you clone, someone merges a branch into main. Then, you’d like to create a new branch to do some work. If you create your branch off of main before operating git pull , your branch will not have the most recent changes. You could accidentally introduce a conflict, or duplicate changes. By running git pull before you create a brach, you can be sure that you will be working with the most recent information.

Undo A git pull

To effectively «undo» a git pull , you cannot undo the git fetch — but you can undo the git merge that changed your local working branch.

To do this, you will need to git reset to the commit you made before you merged. You can find this commit by searching the git reflog . The reflog is a log of every place that HEAD has pointed — every place that you have ever been checked out to. This reflog is only kept for 30 to 90 days, depending on the commit, and is only stored locally. (The reflog is a great reason not to delete a repository if you think you’ve made a mistake!)

Run git reflog and search for the commit that you would like to return to. Then, run git reset —hard <SHA> to reset HEAD and your current branch to the SHA of the commit from before the merge.

Force git pull to Overwrite Local Files

If you have made commits locally that you regret, you may want your local branch to match the remote branch without saving any of your work. This can be done using git reset . First, make sure you have the most recent copy of that remote tracking branch by fetching.

git fetch <remote> <branch>
ex: git fetch origin main

Then, use git reset —hard to move the HEAD pointer and the current branch pointer to the most recent commit as it exists on that remote tracking branch.

git reset —hard <remote>/<branch>
ex: git reset —hard origin/main

_Note: You can find the remotes with git remote -v , and see all available remote tracking branches with git branch —all .

git pull with Rebase

If there have been new commits on both your local branch and the remote branch, a merge commit will be created when you git pull . This recursive merge is the default merge style when there are two splits in history being brought together. But, you may want history on a branch to be only one line.

You can update your local working branch with commits from the remote, but rewrite history so any local commits occur after all new commits coming from the remote, avoiding a merge commit.
This is done with git pull —rebase .

Using git pull —rebase does not affect the integrity of the changes or the commits, but it does affect how history looks in the commit parent/child relationship.

• git clone [url] : Clone (download) a repository that already exists on GitHub, including all of the files, branches, and commits.
• 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 branch : This shows the existing branches in your local repository. You can also use git branch [banch-name] to create a branch from your current location, or git branch —all to see all branches, both the local ones on your machine, and the remote tracking branches stored from the last git pull or git fetch from the remote.
• git push : Uploads all local branch commits to the remote.
• git log : Browse and inspect the evolution of project files.
• git remote -v : Show the associated remote repositories and their stored name, like origin .

Get started with git and GitHub

Review code, manage projects, and build software alongside 40 million developers.

Git, как обновить проект ?

Недавно начал работать с Git и столкнулся со следующей ситуацией:

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

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

Как я понял удалять заново устанавливать и настраивать все файлы не вариант. Подскажите пожалуйста что нужно сделать ?

• Вопрос задан более трёх лет назад
• 80250 просмотров

• Facebook
• Вконтакте
• Twitter

• Facebook
• Вконтакте
• Twitter

Вам нужен центральный репозиторий, в который вы сможете загружать ваши новые правки с помощью git push (с любого компьютера), и из которого сможете загружать их в любое место, где у вас этот репозиторий склонирован, с помощью git pull. См. раздел о работе с удалёнными репозиториями в документации по Git.

Вообще говоря, git позволяет работать и в полной децентрализации, но это в общем случае менее удобно.

Так вот. Самое простое — воспользуйтесь услугами Github, хранить у них репозитории получается надёжно и недорого.

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

На практике последовательность действий, которые вам нужно совершить, описана здесь.

Вкратце — создаёте bare-репозиторий, загружаете на сервер, и указываете его адрес в качестве origin у себя в локальном репозитории (а также в любых других местах, где есть этот репозиторий — например, у вас же на сервере):

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

При этом remote при клонировании выставляется автоматически.

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

Git: 4 наиболее частых действия в примерах

Итак, у вас есть ссылка на github и вы хотите скачать эти файлы к себе на компьютер. Здесь все просто. Можно пройти по ссылке и нажать кнопку Download zip . Вы скачаете решение к себе на компьютер в виде zip файла. Но преимуществ использования системы контроля версий у вас нет.

Второй способ – сделать копию с помощью консоли. Для этого:

• создаем папку, в которую будем скачивать файлы.
• Вызываем контекстное меню папки и в нем выбираем пункт Git bash here
• В открывшейся консоли набираем команду:

$ git clone https://github.com/luschenko/pulse_bg.git

Где https://github.com/luschenko/pulse_bg.git — адрес github репозитория.

В результате – у вас появилась копия репозитория на жестком диске.

Потренироваться в клонировании репозитория на локальный компьютер можно с помощью данного урока, в нижней части которого приведена ссылка на GitHub

Обновляем копию репозитория на локальном диске

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

Команда создаст репозиторий

Добавьте в репозиторий папки и файлы внутри текущей:

$ git pull https://github.com/luschenko/pulse_bg.git

Скачайте обновления из удаленного репозитория

Теперь у вас самая новая версия локального репозитория.

Создать локальный репозиторий

Вы сделали проект. Теперь на его основе хотите создать репозиторий. Выполняем:
Кликаем правой кнопкой мыши на папке, в контекстном меню выбираем Git Bash Here.

Для начала нужно создать репозиторий:

Скачайте обновления из удаленного репозитория

Затем добавить в репозиторий файлы и папки проекта

Проверить состояние репозитория можно с помощью команды git status

$ git commit -m «stage 1»

Итак, проект создан, изменения в нем отслеживаются. Создаем слепок состояния проекта (коммит).

Все, проект готов. Можно отправлять его на git.

Отправка коммита на git

Создадим на GitHub новый репозиторий. Для этого перейдем https://github.com/ и нажмем кнопку + New repository . Внесите имя репозитория.
Скопируйте адрес репозитория, он представлен строкой вида https://github.com/luschenko/t1.git

Теперь в консоли git bash выполните команду:

$ git push -u https://github.com/luschenko/t1.git master

Система потребует логин и пароль. Внесите ваш логин и пароль от GitHub. Дождитесь загрузки репозитория.

Обновить удаленный репозиторий

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

запустите Git Bash и добавьте файлы для последующего коммита:

$ git commit -m «stage 1»

Залейте коммит на удаленный репозиторий

$ git push -u https://github.com/luschenko/t1.git master

Системы контроля версий типа Git и препроцессоры HTML и СSS являются незаменимыми инструментами в командной работе.

Шпаргалка по основам Git/GitHub

Если Вы всё еще не знакомы с системой контроля версий и её использование не входит в Ваш рабочий процесс, то сейчас — самое время начать! Это основополагающее руководство поможет Вам начать работу с Git и даст Вам прочный фундамент для дальнейшего развития. Git почти наверняка используется на любом серьёзном проекте и чем раньше Вы научитесь им пользоваться, тем более ценным сотрудником Вы станете для работодателей. Так же, это улучшит Ваш личный опыт, так как Вы без проблем сможете переключаться между несколькими компьютерами, не волнуясь при этом о переносе проекта через флэш накопители… Работа в команде станет гораздо легче. Бывали ли у Вас случаи, когда код становился настолько запутанным, что казалось, будто было бы легче начать проект с нуля? С системой контроля версий Вы сможете просто вернуться к стабильной версии, без всего того что Вы успели воплотить в 4 часа утра.

Git и GitHub

Git — это одна из систем контроля версий. По существу это значит, что она хранит всю историю изменений проекта. История Вашего проекта и история изменений этого же проекта у Ваших коллег — у всего будет копия. Это полная противоположность SVN, где вся история изменений храниться в одном месте.

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

Введение

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

Первым делом мы загрузим Git. Для пользователей Windows я советую установить и Git Bash, который доступен после установки Git. Для пользователей Mac, использование Terminal будет достаточным. После завершения установки приступайте к регистрации аккаунта GitHub. Итак, у Вас есть Git, инструмент командной строки, и GitHub аккаунт, куда Вы будете загружать свои репозитории.

Шпаргалка

Используя Git Bash или Terminal перейдите в корневую директорию проекта. Если Вы используете Git Bash, то с помощью правого клика можно выбрать “Git Bash Here” и он запустится в рабочей директории.

git init
Эта команда создаст .git репозиторий в Вашем проекте. Репозиторий или “repo” это коллекция всех изменений, которые были совершены на протяжении всего времени после инициализации репозитория. Это первое что нужно сделать для нового проекта.

git config —global user.name "Ваше Имя"
git config —global user.email "ВашаПочта@mail.com"
Эти команды определят информацию, которая будет использоваться при каждом commit(фиксирование изменений). Их стоит выполнить всего один раз при первичной установке Git.

git add имяФайла.расширение
Замените “ имяФайла.расширение” на любой файл, изменения которого Вы пытаетесь зафиксировать, например “index.html”. Эта команда добавит файл в “staging area”(участок подготовки). Воспринимайте staging area, как секцию в которой файлы проходят подготовку к перемещению в Ваш репозиторий.

git add .
Если Вы хотите добавить всё из директории проекта в staging area, то эта команда сделает всё сама.

git add *.html
Если Вы хотите добавить все файлы с расширением .html в staging area то эта команда отлично подойдет. Расширение можно менять в зависимости от предпочтений.

git status
Покажет что уже было добавлено в staging area и какие файлы были изменены и ждут перемещения в staging area.

git reset имяФайла.расширение
Убирает выбранный файл из staging area.

git rm —cached имяФайла.расширение
Убирает файл из staging area и определяет его как игнорируемый.

git commit -m "Описание коммита"
Берёт файлы из staging area и “фиксирует” их в Ваш локальный репозиторий. В кавычки следует вставить краткое описание изменений для конкретного коммита. Постарайтесь описать коммит краткими деталями, например: “устранил проблему при изменении имени пользователя” вместо подобных сообщений “какие-то изменения”

touch .gitignore
Эта команда создаст файл с названием .gitignore. Вы можете открыть этот файл в текстовом редакторе и прописать названия файлов или директорий, изменения в которых Вы не хотели бы отслеживать (они будут игнорироваться Git). Изменения в игнорируемых файлах не будут отображаться при выполнении git status .

git branch названиеВетки
Создает сущность, называемую branch(ветвь). Ветвь — это точная копия Ваших файлов.

git checkout “названиеВетки”
Позволит Вам переключить контроль над созданной Вами веткой и работать в её пределах. Здесь Вы можете совершать любые изменения кода. Когда Вы будете готовы можно совершить commit изменений и отправить изменения в GitHub (об этом ниже) или же можно удалить ветвь, если что-то пошло не так или Вам больше не нужны изменения сделанные в этой ветке.

git merge названиеВетки
Находясь в Master(главной) ветви, Вы можете использовать эту команду, чтобы взять коммиты из любой из ветвей и соединить их вместе.

git remote add origin https://github.com/имяПользователя/проект.git
Эта команда определит “местоположение” Вашего удалённого репозитория. Всё что было до этого происходило исключительно в локальном репозитории на Вашем компьютере. Вам нужно будет перейти в GitHub аккаунт и создать новый удалённый репозиторий, куда Вы сможете отправлять изменения из локального репозитория. After you created your remote repository you will be provided with a link and that link is the location you will want to use in the above command.

git remote
Выведет список из всех удалённых репозиториев, которые были добавлены к Вашему проекту.

git push -u origin master
Эта команда отправит локальные изменения в удалённый репозиторий. Таким образом эту команду стоит прописывать только первый раз.

git push
This is what you will use to push your code to GitHub after your initial push.

git clone https://github.com/имяПользователя/проект.git
Если у Вас отсутствует проект на личном или рабочем компьютере, то эта команда поможет клонировать/загрузить весь проект в текущую директорию.

git pull
Если Вы работаете над одним и тем же проектом с несколькими людьми, то эта команда позволит загрузить последнюю версию из удалённого репозитория и обновить вашу локальную версию.

Вывод

Надеюсь это руководство поможет Вам начать и понимать что вообще происходит. Буду рад помочь с уточнениями и ответами на вопросы в комментариях.