In this example, planets.md will say there are eight planets. With your working copy in this ‘detached HEAD’ state, you will see the files exactly as they were when the commit was written to git. This is great for poking around in your git history, but you will eventually want to either check out one of your branches or you will want to create a new branch with this commit as its head. This means your working copy is showing a state of the repository that is not the HEAD of any of your branches. This will warn you that “You are in ‘detached HEAD’ state.”. You can make the working copy of your git repository match the state in that commit by running The first 8 characters will be enough to uniquely identify the hash, so we’ll use ca41886d in the example. For this example, we will pretend the hash for that commit is ca41886daca7f55aa7d88a5ae7b226dd3e670739. For example, the hash for the commit with the log message “pluto is not a planet.”. Run git log and pick the commit hash for any of the old commits. To do this, you need the commit hash from running git log. You can also restore a specific state from your history by checking out that commit. You will see that the git history in branch-master contains all of the commits from the other branches, with exactly the same commit messages and hashes. To confirm this, compare the commit hashes that you see when you run git log master against the commit hashes in each of the other branches. Now that you’ve merged your work into the main master branch, you can delete all of the other branches without losing any history because the master branch actually contains all of the work from all of the branches, including the entire history of changes. Step: Confirm that the master branch has your whole history With the branch-master branch checked out, merge the work from branch-a to branch-master by running $ git checkout -b branch-master Step: Start merging the work into the fake “master” branch Now create a new “branch-master” branch where we will combine everyone’s work $ git checkout planets-before-merge-conflict To create the fake “master” branch, checkout the planets-before-merge-conflict branch which contains the original version of planets.md by running This will let us compare all of the stages of the process before we finish. In normal use, you would merge these changes into the master branch, but for the purposes of this exercise we will create a fake “master” branch. On branch-a there is a commit with the message “sets the correct number of planets” while on branch-b there is a commit with the message “pluto is not a planet.” the commit messages are different AND the commit hashes are different. When you compare these two commits, you should see that both of them have the original commit with the message “planets.md before merge conflict” and that commit hash is the same in both branches but each branch has a different commit after this one. Sometimes you realise you’re in a bit too deep on this merge conflict - in which case you can undo it by running git merge -abort.Output the commit history for each branch by running We can also see the conflicting commits by running git log -merge Aborting your merge during a merge conflict Here, everything after ++> main represents the branch you are merging in. Next, we can use git diff to see the difference between this branch and the one we are merging into: ++> main No changes added to commit (use "git add" and/or "git commit -a" )Īs we can see, only file.md is affected. " to mark resolution ) both modified: file.md (fix conflicts and run "git commit" ) (use "git merge -abort" to abort the merge ) Unmerged paths: Once you review all conflicts, you can then add your files and commit them as normal: “Compare Changes” - this will bring up an additional screen to compare changes side by side.“Accept Both Changes” - this will keep both, one under the other.“Accept Incoming Changes” - this will use the content from the branch you are merging in.“Accept Current Changes” - this will use your current branch’s content.In Visual Studio Code, this is represented in conflicting files via the GUI shown below. This provides a pretty easy way to fix your conflicts. If you’re using a modern code editor like Visual Studio Code, then merge conflicts will appear in the GUI where you can accept incoming changes or accept the current changes on your branch. How to resolve merge conflicts in git via GUI If we run into merge conflicts now, we need to resolve them. Now that our branch is stabilised, we can try to run git merge my-branch (where my-branch is your branch) to merge our branch back into main.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |