![]() ![]() To proceed, you will need to have high level permissions (at least write permissions, I think). This is a really good idea, but it stands in the way of this task. GitHub has a protected branch feature that prevents force pushes to certain branches in a repository. Unable to force push into protected branch Using our team’s example, everyone had to run git fetch -all and git reset -hard origin/master from their local master branch in order to synchronise with the remote’s.įorgetting to do so may cause some mess, so remember to announce to the whole team twice that you’d just rewritten a remote branch’s code and history, and get them to run the necessary commands before continuing work. Team members’ local branch became off-sync with remote’s ![]() Below are some of them and how I worked around them. But I faced some difficulties along the way the first time. I’ve tried it a few times now, and it always perfectly duplicates the code and git history of one branch into another. force pushing a branch to a remote will force the remote branch to take on the branch’s code and git commit history.git branch names are just pointers, so renaming staging to master and doing a git push origin master will update remote’s master.git reset -hard origin/master forces your local master’s latest commit to be aligned with remote’s.git fetch -all downloads all objects and refs from the entire repository without merging.git branch -m renames the current branch to ‘new-name’.$ (master ) git reset -hard origin/master # Force push staging (now master) into remote master # Rename master to old-master, staging to master How to completely replace one branch’s code and git history with another Or more accurately, we force-pushed the staging branch into the master branch. It just felt cleaner, and it probably also represents the state of the 2 branches more clearly as being in sync as they ought to be. However, even after figuring this out, we still wanted to square off the differences between staging and master by replacing master’s git branch code and commit history. That was the reason for the commit count mismatch. Each PR created one extra commit on master. It’s just that whenever we close a pull request (PR) on GitHub, our team protocol is to hit the “Merge” button, which merges all the commits from the PR into master, but not without adding one extra commit at the top called the “merge commit”. Code that exist on master must therefore already exist in staging, right? That shouldn’t be the case, because our deployment pipeline has always been to go from feature -> staging -> master. How to completely replace git branch code with another branch's code published: Īt work recently, our CTO noticed that our main repository’s staging branch had over 80 less commits than master.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |