Merge branch '1234/awesome-feature-branch' Resolved 'README.txt' using previous resolution. HEAD is now at 9e625ab Adding an upstream commit. | * 9e625ab - (origin/master, origin/HEAD) Adding an upstream commit. Never do git reset on a real public branch!įatal: Not possible to fast-forward, aborting. The following was done after I undid the above merges in both repositories using git reset. Better yet, let's alias that command to git pl by running git config -global 'pull -ff-only'. How could we have done this better? Instead of using git pull, let's use git pull -ff-only. | * dff13db - (1234/awesome-feature-branch) Adding a downstream commit. * 46208d7 - (HEAD, origin/master, origin/HEAD, master) Merge branch 'master' of /tmp/upstream ( 14:49:38 -0400) What does our history graph look like now? Remote: Total 3 (delta 1), reused 0 (delta 0)ĬONFLICT (content): Merge conflict in README.txtĪutomatic merge failed fix conflicts and then commit the result. Remote: Compressing objects: 100% (2/2), done. 'Note about fast-forwards' section of 'git push -help' for details. To prevent you from losing history, non-fast-forward updates were rejected ! master -> master (non-fast-forward)Įrror: failed to push some refs to '/tmp/upstream' Time to push up our merge and share it with the world! We've completed our feature branch, and have merged it to our local copy of master. Adding a downstream commit.ĭownstream/ $ git merge -no-ff 1234/awesome-feature-branch Switched to a new branch '1234/awesome-feature-branch'ĭownstream/ $ echo 'Adding a downstream commit before pulling into my local master branch.' > README.txtĭownstream/ $ git commit -m 'Adding a downstream commit.' This simulates parallel development between two different developers:ĭownstream/ $ git checkout -b 1234/awesome-feature-branch The next step is to add a feature branch and merge commit to the downstream clone. Upstream/ $ git commit -m 'Adding an upstream commit.' Upstream/ $ echo 'Adding another upstream commit.' > README.txt Now that we have our upstream repository with one commit on master, and a downstream clone of it, let's add another commit to the upstream repository: Adding a README file.ġ files changed, 1 insertions(+), 0 deletions(-) Upstream/ $ git commit -m 'Adding a README file.' Upstream/ $ echo 'Demo for how to handle upstream commits after you have merged into the upstream branch.' > README.txt Upstream/ $ git config -local n圜urrentBranch ignore # This allows us to push into upstream even when it has a branch checked out Initialized empty Git repository in /private/tmp/upstream/.git/ First, let's create two temporary git repositories: "upstream", to represent the remote repository, and "downstream", to represent your local clone of the repository. Let's take a look at an example of how this situation can happen, and a way to resolve it cleanly. Then, when you push your changes up, you end up with both a merge from the remote integration branch into your local branch, and a merge from your feature branch into the integration branch. Since your local commit isn't on the remote repository yet, when git pull runs git merge origin/, it will automatically do a "recursive" merge and create a commit with the remote changes. What are these commits, and how did they get created? Usually, it's the result of adding a commit to your local copy of a branch, and then pulling upstream changes into that branch. If you're just starting out with Git, you'll inevitably run into commits into your feature branches like the following:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |