開発ブランチをマスターとマージする

つまり、GitHubリポジトリに2つのブランチがmasterありdevelopmentます。示されているように、開発ブランチですべての開発を行っています。

git branch development
git add *
git commit -m "My initial commit message"
git push -u origin development

次に、developmentブランチのすべての変更をにマージしたいと思いmasterます。私の現在のアプローチは：

git checkout master 
git merge development
git push -u origin master 

私が従う手順が正しいかどうか教えてください。

私は一般的に最初のものにマージ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)

2つのアプローチに大きな違いはありませんが、ブランチをマージしたmaster後、まだマージしたくない場合や、マージする前に行う必要がある作業がまだあることに気づきました。、だから私はmaster最後のものまで手つかずのままにする傾向があります。

編集：コメントから

誰がいつマージしたかを追跡したい場合は、マージ--no-ff中にflagを使用できます。ワークフローで（最初のステップ）に複数回マージする必要があり、これらのコミットノードを作成してもあまり役に立たない可能性があるため、これは一般に（最後のステップ）にマージdevelopmentする場合にのみ役立ちます。mastermasterdevelopment

git merge --no-ff development

個人的には、私のアプローチはあなたのアプローチに似ており、マスターに戻ったときにいくつかのブランチとコミットのスカッシュがあります。

私の同僚の1人は、ブランチをあまり切り替える必要がなく、次のようなものをすべて開発ブランチから実行して、開発ブランチにとどまっています。

git fetch origin master

git merge master

git push origin development:master

1行目は、前回のローカルリポジトリの更新以降、マスターになるために行われたアップストリームコミットがあることを確認します。

2番目は、それらの変更（ある場合）をマスターから開発にプルします

3番目は、開発ブランチ（現在は完全にマスターとマージされています）をorigin / masterにプッシュします。

彼の基本的なワークフローは少し間違っているかもしれませんが、それがその主な要点です。

枝の知識がなくてここに来た人のために下から説明。

基本的なマスターブランチ開発ロジックは次のとおりです。別のブランチでのみ作業し、マスターを使用して別のブランチをマージします。

この方法で新しいブランチの作成を開始します。

1）ローカルディレクトリにリポジトリを複製（または新しいリポジトリを作成）：

$ cd /var/www
$ git clone git@bitbucket.org: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 shouldn’t 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を使用することを強くお勧めします。

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/

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

はい、これは正しいですが、統合の準備ができる前に変更をバッファリングするだけの非常に基本的なワークフローのように見えます。gitがサポートするより高度なワークフローを検討する必要があります。複数の機能を並行して作業できるトピックブランチアプローチや、現在のワークフローを少し拡張する卒業アプローチが好きかもしれません。

MacまたはUbuntuを使用している場合は、ブランチの作業フォルダーに移動します。ターミナルで

harisdevがブランチ名であるとします。

git checkout master

追跡されていないファイルまたはコミットされていないファイルがある場合、エラーが発生し、追跡されていないファイルまたはコミットされていないファイルをすべてコミットまたは削除する必要があります。

git merge harisdev 

git push origin master

ブランチを削除する最後のコマンド。

$ git branch -d harisdev

ステップ1

新しい「dev」ブランチを作成して切り替えます。ローカルのgitファイルはリモートと同期していますが、「dev」ブランチはまだ存在していません。

git branch dev # create
git checkout dev # switch
# No need to git add or git commit, the current
# branch's 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.

これは私が通常行う方法です。まず、変更をマスターにマージする準備ができていることを確認します。

1. リモートサーバーからの最新の変更で開発が最新かどうかを確認します。 git fetch
2. フェッチが完了すると git checkout master。
3. 実行して、マスターブランチに最新の更新があることを確認します。 git pull
4. 準備が完了したら、次のようにしてマージを開始できます git merge development
5. 変更をプッシュするとgit push -u origin master完了です。

記事では、gitのマージについて詳しく説明しています。

1）ブランチ開発で、次のコマンドを使用してgitステータスを確認します。

git status

コミットされていないコードがあってはなりません。そうであれば、コードを開発ブランチにプッシュします。

git add *

git commit -m "My initial commit message"

git push origin Development

2）開発ブランチで、次の2つのコマンドを実行します。

git branch -f master HEAD

git push -f origin master

開発ブランチコードをマスターブランチにプッシュします。

@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応答を確認します。

2つ目はマージを実行し、競合を作成して解決できます。

その後、マスターをチェックアウトしてマスターに切り替えることができます。

次に、開発ブランチをローカルマスターにマージします。no-ffフラグは、マージ全体を追跡可能にするために、マスターにコミットノードを作成します。

その後、マージをコミットしてプッシュできます。

この手順により、開発からマスターへのマージコミットが確実に表示され、開発ブランチを見ると、開発中にそのブランチに対して行った個々のコミットを確認できます。

必要に応じて、開発ブランチで行われた内容の概要を追加する場合は、マージコミットをプッシュする前に修正できます。

編集：私の元の答えgit merge masterは何もしないことを提案しgit merge FETCH_HEADました、オリジン/マスターをフェッチした後に行う方が良いです

開発ブランチを「チェックアウト」すると、...

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

 git checkout master 
 git merge dev
 git push origin master 

gerritを使用している場合、次のコマンドは完全に機能します。

git checkout master
git merge --no-ff development

デフォルトのコミットメッセージで保存できます。変更IDが生成されていることを確認してください。次のコマンドを使用して確認できます。

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プロジェクト管理者は、「refs / for / refs / heads / master」または「refs / for / refs / heads / *」という名前の別の参照をgerritに作成する必要があります（将来、すべてのブランチをカバーする予定です）。次に、この参照に対する「プッシュマージコミット」権限と、GCRを送信する必要がある場合は「送信」権限を付与します。

さて、上記のpushコマンドをもう一度試してみてください。うまくいくはずです。

クレジット：

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

https://stackoverflow.com/a/21199818/3877642

最も簡単な解決策は

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

これにより、使用中のすべてのブランチの履歴も保持されます

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