Слияние с филиалом

Ответ 1

Мне обычно нравится сначала объединить master в development, так что, если есть какие-либо конфликты, я могу разрешить в самой ветке development, а мой master остается чистым.

(on branch development)$ git merge master
(resolve any merge conflicts if there are any)
git checkout master
git merge development (there won't be any conflicts now)

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

ИЗМЕНИТЬ: Из комментариев

Если вы хотите отслеживать, кто сделал слияние и когда, вы можете использовать флаг --no-ff при слиянии для этого. Это обычно полезно только при объединении development в master (последний шаг), поскольку вам может потребоваться слияние master в development (первый шаг) несколько раз в вашем рабочем процессе и создание фиксации node для них это может быть не очень полезно.

git merge --no-ff development

Ответ 2

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

Один из моих коллег не любит, когда приходится так часто переключать ветки, и остается в ветке разработки, выполняя что-то похожее на следующее, выполняемое из ветки разработки.

git fetch origin master

git merge master

git push origin development:master

Первая строка проверяет наличие у него каких-либо восходящих коммитов, которые были сделаны мастером с момента последнего обновления его локального репозитория.

Второй вытягивает эти изменения (если они есть) из мастера в разработку

Третий переводит ветку разработки (теперь полностью объединенную с master) до origin/master.

Я могу немного ошибиться в его базовом рабочем процессе, но в этом его основная суть.

Ответ 3

Объяснение снизу для тех, кто пришел сюда без каких-либо знаний о ветвях.

Основная логика разработки основной ветки такова: вы работаете только с другими ветками и используете master только для объединения других ветвей.

Вы начинаете создавать новую ветку следующим образом:

1) Клонировать нужное хранилище в корень вашего веб-сайта:

$ cd /var/www
$ git clone [email protected]:user_name/repository_name.git

2) Создать новую ветку. Он будет содержать последние файлы вашего основного ветки хранилища

$ git branch new_branch

3) Измените ветку git на new_branch

$ git checkout new_branch

4) Заниматься кодированием, коммитами, как обычно…

$ git add .
$ git commit -m "Initial commit"
$ git push (pushes commits only to "new_branch")

5) Когда работа в этой ветки будет завершена, объедините ее с "основной" веткой:

$ git merge master
$ git checkout master (goes to master branch)
$ git merge development (merges files in localhost. Master shouldnt have any  commits ahead, otherwise there will be a need for pull and merging code by hands!)
$ git push (pushes all "new_branch" commits to both branches - "master" and "new_branch")

Обновление: я настоятельно рекомендую использовать GitKraken для этого, чтобы видеть визуальное дерево изменений и лучше видеть всю логику и коммиты.

Ответ 4

Было бы здорово, если бы вы могли использовать рабочий процесс Git Flow. Он может легко объединить развивающуюся ветку в мастерскую.

То, что вы хотите сделать, это просто следовать инструкции git-flow, упомянутой здесь:

ШАГИ:

• настроить проект git-flow
• создавать ветки и объединять все для развития
• запустите команду git flow release start <version_number>
• затем предоставьте содержательное сообщение для релиза
• выполните команду git flow release finish <version_number>
• он объединит все в master и изменит ветку на master.
• выполните команду git push чтобы опубликовать изменения на удаленном мастере.

Для получения дополнительной информации посетите страницу - http://danielkummer.github.io/git-flow-cheatsheet/

Ответ 5

1. //pull the latest changes of current development branch if any        
git pull (current development branch)

2. //switch to master branch
git checkout master 

3. //pull all the changes if any
git pull

4. //Now merge development into master    
git merge development

5. //push the master branch
git push origin master

Ответ 6

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

Ответ 7

Если вы находитесь на Mac или Ubuntu, перейдите в рабочую папку ветки. В терминале

предположим, что harisdev - это branchname.

git checkout master

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

git merge harisdev 

git push origin master

Последняя команда для удаления ветки.

$ git branch -d harisdev

Ответ 8

Шаг 1

Создайте и переключитесь на новую ветку "dev" , где локальные файлы git синхронизированы с удаленным, но ветвь "dev" еще не существует.

git branch dev # create
git checkout dev # switch
# No need to git add or git commit, the current
# branch files will be cloned to the new branch by-default.
git push --set-upstream origin dev # push the "dev" branch to the remote.

Шаг 2

Внесите свои изменения в ветку "dev" (ваш текущий, если вы выполните шаг 1), зафиксируйте и надавите на удаленный ветвь "dev" .

git add .
git commit -S -m "my first commit to the dev branch" # remove the -S if you're not "secure", secure = when you already setup crypto private and public keys (i.e "verified" green sign in github)
git push -u origin dev # push the changes to the remote, -u origin dev is optional but good to use.

Шаг 3

Объедините ветвь "dev" в "master".

git checkout dev # switch to "dev" branch if you're not already.
git merge master # optionally, this command is being used to resolve any conflicts if you pushed any changes to your "master" but "dev" doesn't have that commit.
git checkout master # switch to "master", which is the branch you want to be merged.
git merge --no-ff dev # merge the "dev" branch into the "master" one.

Ответ 9

Вот как я обычно это делаю. Во-первых, убедитесь, что вы готовы объединить свои изменения в мастер.

1. Проверьте, соответствует ли разработка последним изменениям с вашего удаленного сервера с помощью git fetch
2. Как только выборка будет завершена, git checkout master.
3. Убедитесь, что главная ветвь имеет последние обновления, выполнив git pull
4. После завершения подготовки вы можете начать слияние с помощью git merge development
5. Нажмите на изменения с помощью git push -u origin master и все готово.

Вы можете узнать больше о git merging в статье.

Ответ 10

1) В отделе разработки проверьте статус git с помощью следующей команды:

git status

Там не должно быть незафиксированного кода. Если это так, отправьте ваш код в ветку Разработка:

git add *

git commit -m "My initial commit message"

git push origin Development

2) В ветке Разработка запустите следующие две команды:

git branch -f master HEAD

git push -f origin master

Это подтолкнет ваш код ветки разработки в основную ветку.

Ответ 11

Основано на @Sailesh и @DavidCulp:

(on branch development)
$ git fetch origin master
$ git merge FETCH_HEAD
(resolve any merge conflicts if there are any)
$ git checkout master
$ git merge --no-ff development (there won't be any conflicts now)

Первая команда убедится, что у вас есть все вышестоящие коммиты, сделанные удаленному мастеру, с ответом Sailesh, который не произойдет.

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

После этого вы можете наконец оформить заказ мастера, чтобы переключиться на мастер.

Затем вы объединяете ветку разработки с локальным мастером. Флаг no-ff создаст узел фиксации в master для отслеживания всего слияния.

После этого вы можете зафиксировать и нажать свое слияние.

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

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

РЕДАКТИРОВАТЬ: мой оригинальный ответ предложил git merge master который ничего не делал, лучше сделать git merge FETCH_HEAD после выборки origin/master

Ответ 12

Как только вы "оформили" ветку разработки, вы...

 git add .
 git commit -m "first commit"
 git push origin dev
 git merge master

 git checkout master 
 git merge dev
 git push origin master 

Ответ 13

Я думаю, что самое простое решение было бы

    git checkout master
    git remote update
    git merge origin/Develop -X theirs
    git commit -m commit -m "New release"
    git push --recurse-submodules=check --progress "origin" refs/heads/Master

Это также сохраняет историю всех используемых веток

Ответ 14

Если вы используете Gerrit, следующие команды работают отлично.

git checkout master
git merge --no-ff development

Вы можете сохранить с сообщением фиксации по умолчанию. Убедитесь, что идентификатор изменения сгенерирован. Вы можете использовать следующую команду, чтобы убедиться.

git commit --amend

Затем нажмите следующую команду.

git push origin HEAD:refs/for/refs/heads/master

Вы можете столкнуться с сообщением об ошибке, как показано ниже.

! [remote rejected] HEAD -> refs/for/refs/heads/master (you are not allowed to upload merges)

Чтобы решить эту проблему, администратор проекта gerrit должен создать еще одну ссылку в gerrit с именем 'refs/for/refs/head/master' или 'refs/for/refs/head/*' (которая будет охватывать все ветки в будущем). Затем предоставьте разрешение "Push Merge Commit" на эту ссылку и разрешение "Отправить", если требуется отправить GCR.

Теперь попробуйте вышеупомянутую команду push, и она должна работать.

Кредиты:

https://github.com/ReviewAssistant/reviewassistant/wiki/Merging-branches-in-Gerrit

fooobar.com/questions/1182436/...

Ответ 15

1. //push the latest changes of current development branch if any        
git push (current development branch)

2. //switch to master branch
git checkout master 

3. //pull all the changes if any from (current development branch)
git pull origin (current development branch)

4. //Now merge development into master    
git merge development

5. //push the master branch
git push origin master

Error
To https://github.com/rajputankit22/todos-posts.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/rajputankit22/todos-posts.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Then Use 
5. //push the master branch forcefully
git push -f origin master