Incredible video Dana!! This was, and has been, a lifesaver. I come back to this video every time I have to deal with a merge-conflict in sourcetree. Thank you so much!!
Great tutorial series. One question though: Why didn't you push to the remote branch DanaW, so as to bring that up to date, before attempting a pull request?
At 1:57, you'll see a checkbox that says "Push changes immediately to origin/ DanaW" - this automatically updates the remote branch so that i don't have to perform a separate push. You want to be careful using this feature, but in this case, since i am committing to a branch that no one else should be using, i can safely use this!
Hello Dr. Dana, might you have made a mistake by saying "before I attempt to make a Pull request", when you meant to say "before I attempt to make a push request" @02:42? Or am I just confused?
Great question, those terms are confusing! The difference between a pull request and a push (there is no push request) is that a pull request is used when an approval process is in place and you want to request that your supervisor approve your changes before they are merged into master. If you're working on your own and not in a team, you can just push directly to master. The terminology is a little odd, but those are the standard terms used with git. Thanks!
Many of the features are available in both. VS Code is a little less fully featured than Community or Enterprise (the true professional's version). There are some limitations on both sides, for example VS Code can run Java but VS Community cannot. I think there is something that Community can do that VS Code can't, but I don't remember off the top of my head. Community will better prepare you for professional tools and work. This is a decent run-down of the main decision points: www.infoworld.com/article/3436860/visual-studio-code-vs-visual-studio-how-to-choose.html
I'm not quite certain what you mean. Conflicts arise when there are 2 sets of changes made to the same code. Are you sure that the changes you made conflicted with the changes someone else made (like you both had to change the same file)? If the changes made are mutually exclusive and don't overlap, then git/sourcetree will merge them automatically and not present a merge conflict.
Thanks, Dana! I'm new to SourceTree, how to handle the branch after merge to master? I try to delete the branch, the red label with "branch" name disappear but the graph still showing the [origin/{branch name}] which is in RED color. Do you know why?
Hmmm...I don't know, I've tried a few variations to try and replicate that behavior and I can't get the same thing to happen. But if you right-clicked on the branch name in sourcetree's branch list (left-hand side panel) and then selected Delete, all that does is delete your local branch, so perhaps you're still seeing the remote branch? If you deleted the branch through github/bitbucket, then try performing a Fetch -> Fetch all/Prune all/Update tags and see if that gets rid of those red labels.
Great Video. All videos i see are working with only 1 file that has conflicts. I am looking for a scenario where 1 file is in conflict and there are some new changes in the branch where i will be raised pull request. I have a question. Our process is little different. We are using bitbucket Can you let me know what would be the right way to do it master every week we create release_week each developers creates branches for bugs from master, after that pull request to release and merge it. I have a case where i modified 2 files. when i created pull request to release, it showed merge conflict on one file. I followed similar to above steps git pull origin releasebranch this bought all the files that are changed in release (master to release) to my local. 1 merge conflict file and 5 files that have changes in release branch I resolved the merge conflict of the one file it complained. -- But i need to push all the other files from release again to my branch. This will show up like i made changes to the files in the pull request. Those changes are from release branch, i did not change them. can you tell me the better way to do it so that my pull request will have only the changes needed. I don't need to show automerge files that are in release as new changes in my branch.
If I'm understanding your question correctly, when you pulled from master into your local branch, it showed 1 conflict (which you resolved) and then 5 additional files that you will need to add to your branch. Unfortunately, this is a necessary step in the process of getting your work to be merged into master - you will need to pull the changes from master into your branch, commit them, test your branch again to make sure everything still works as it did before, and then you can do the pull request to master. The reason you always need to pull master's changes into your branch is to ensure that those changes will not conflict with yours in some way. Think about it this way - if you and someone else both modified the same code (thus a conflict) and they added a reference to class X (one of the new files) and you didn't bring class X into your branch, after the conflict resolution - your code would no longer build on your branch since the conflict was resolved to add this new reference to class X (if you didn't keep this reference, you would be throwing away your teammate's work, so yes, it will be integrated into your branch). When you do the pull request to master, it will not show those 5 files as new, github keeps track of when files are added and won't duplicate the addition. However, it will show those 5 files added to your branch in a commit. So, tl;dr - before doing a pull request, always pull from the master branch (or the branch you'll be merging to), integrate any changes into your own branch, test your branch again, commit those changes, and then do the pull request. Any files that were already in master (like the 5 that weren't conflicting) will not be added again. Hope this was helpful!
Unfortunately, it is very difficult to correctly merge scene files unless the changes were minor. Scene files can be stored as text files, but in my experience, it is easier for the team to coordinate changes to scenes and prefabs instead of trying to merge them. It is very difficult to make sure the merge is correct and all the guids are referenced correctly. Since these videos were created specifically for my students, I encourage them to avoid merging scenes and prefabs as the process is error prone. However, take a look at the scene file in your favorite text editor (like notepad++) and you'll see the data is stored in the yaml format. Unity describes this format and the codes for various objects in their documentation. docs.unity3d.com/Manual/TextSceneFormat.html You also have to enable this setting in the editor's project settings.
I'm sorry for any confusion! I tried to be clear in the title by putting VS first indicating that I'd be using VS as the primary merge conflict handling tool. However, at least at the time, Sourcetree did not have a built-in diff tool (usually requiring kdiff or some other external diff tool integration - but even kdiff doesn't compile the code!). I elected to use VS as my external diff tool and encourage others to do the same. VS is the best merging/diff tool since it not only works the same as any other diff tool (3 split panels - mine, theirs, and merged), but it also can show you whether the code can be compiled or not - a feature few (if any) diff tools provide! This is why I use VS for merge conflicts.
![Merge Conflicts and Cherry Pick using Visual Studio (GIT) [March 2021]](/img/1.gif)
Resolve merge conflict with visual studio starts at 3:29
Thanks for letting others know! I created these for my students, which is why there is a little more explanation.
Incredible video Dana!! This was, and has been, a lifesaver. I come back to this video every time I have to deal with a merge-conflict in sourcetree. Thank you so much!!
Wow, what wonderful feedback! Thank you so much! I'm glad it was helpful!
Thanks, Dana! I'm new to Sourcetree, and since it doesn't come with much doc, tutorials like these are just what I need! :)
Awesome, glad they were helpful!
Thanks Dana, You were very helpful.
Thanks! So glad you got some value from it!
Thank you Dana !! Nice video to learn the merging concept!
Thank you so much! I'm glad you learned something useful!
Thank you, Dana!
Thank you so much! Understanding the merge interface in VS2019 was what I was looking for, and you answered it perfectly! :)
Thanks! Glad it was helpful!
Great tutorial Dana. Thanks for posting.
Thank you! Glad it was helpful!
Thanks Dana, currently trying to get to grips with this and your videos have helped :-)
So glad to hear that!
Great tutorial series. One question though: Why didn't you push to the remote branch DanaW, so as to bring that up to date, before attempting a pull request?
At 1:57, you'll see a checkbox that says "Push changes immediately to origin/ DanaW" - this automatically updates the remote branch so that i don't have to perform a separate push. You want to be careful using this feature, but in this case, since i am committing to a branch that no one else should be using, i can safely use this!
@@DrDana I must have missed that. Thanks for clarifying!
@@johndematis8331 i think i talked about it in another video, so in this one it wasn't directly addressed, so you didn't miss anything!
Hello Dr. Dana, might you have made a mistake by saying "before I attempt to make a Pull request", when you meant to say "before I attempt to make a push request" @02:42? Or am I just confused?
Great question, those terms are confusing! The difference between a pull request and a push (there is no push request) is that a pull request is used when an approval process is in place and you want to request that your supervisor approve your changes before they are merged into master. If you're working on your own and not in a team, you can just push directly to master. The terminology is a little odd, but those are the standard terms used with git. Thanks!
This tutorial is still a lifesaver today! Thank you so very much!
Glad it helped!
Thanks, very informative and this series is exactly what I want.
So glad it was helpful!
helped me a lot thanks Doctor.
Great to hear!
I am completely new to visual studio. I see there is Visual Studio Code and Visual Studio. Which one should I use? Thanks!
Many of the features are available in both. VS Code is a little less fully featured than Community or Enterprise (the true professional's version). There are some limitations on both sides, for example VS Code can run Java but VS Community cannot. I think there is something that Community can do that VS Code can't, but I don't remember off the top of my head. Community will better prepare you for professional tools and work.
This is a decent run-down of the main decision points: www.infoworld.com/article/3436860/visual-studio-code-vs-visual-studio-how-to-choose.html
THANK YOU SO MUCH I so appreciate this, so helpful
Thank You Very Much, this is what is was looking for. Saviour.!!
Why my merge conflict pop up / page didnt show??? Its merge the code by themselves..
I'm not quite certain what you mean. Conflicts arise when there are 2 sets of changes made to the same code. Are you sure that the changes you made conflicted with the changes someone else made (like you both had to change the same file)? If the changes made are mutually exclusive and don't overlap, then git/sourcetree will merge them automatically and not present a merge conflict.
Thanks, Dana! I'm new to SourceTree, how to handle the branch after merge to master? I try to delete the branch, the red label with "branch" name disappear but the graph still showing the [origin/{branch name}] which is in RED color. Do you know why?
Hmmm...I don't know, I've tried a few variations to try and replicate that behavior and I can't get the same thing to happen. But if you right-clicked on the branch name in sourcetree's branch list (left-hand side panel) and then selected Delete, all that does is delete your local branch, so perhaps you're still seeing the remote branch? If you deleted the branch through github/bitbucket, then try performing a Fetch -> Fetch all/Prune all/Update tags and see if that gets rid of those red labels.
this was extremely helpful and it's just what i needed so thank you.
Thanks, so glad it helped you!
u deserve more subscribers
Wow! Thank you so much for the encouragement! I will be adding some more content soon, so hopefully that will attract some new people!
Thank you so much for the video..
You're very welcome! Glad it was useful!
Great Video. All videos i see are working with only 1 file that has conflicts.
I am looking for a scenario where 1 file is in conflict and there are some new changes in the branch where i will be raised pull request.
I have a question. Our process is little different. We are using bitbucket
Can you let me know what would be the right way to do it
master
every week we create release_week
each developers creates branches for bugs from master, after that pull request to release and merge it.
I have a case where i modified 2 files. when i created pull request to release, it showed merge conflict on one file.
I followed similar to above steps
git pull origin releasebranch
this bought all the files that are changed in release (master to release) to my local.
1 merge conflict file and 5 files that have changes in release branch
I resolved the merge conflict of the one file it complained.
--
But i need to push all the other files from release again to my branch. This will show up like i made changes to the files in the pull request. Those changes are from release branch, i did not change them.
can you tell me the better way to do it so that my pull request will have only the changes needed. I don't need to show automerge files that are in release as new changes in my branch.
If I'm understanding your question correctly, when you pulled from master into your local branch, it showed 1 conflict (which you resolved) and then 5 additional files that you will need to add to your branch.
Unfortunately, this is a necessary step in the process of getting your work to be merged into master - you will need to pull the changes from master into your branch, commit them, test your branch again to make sure everything still works as it did before, and then you can do the pull request to master.
The reason you always need to pull master's changes into your branch is to ensure that those changes will not conflict with yours in some way. Think about it this way - if you and someone else both modified the same code (thus a conflict) and they added a reference to class X (one of the new files) and you didn't bring class X into your branch, after the conflict resolution - your code would no longer build on your branch since the conflict was resolved to add this new reference to class X (if you didn't keep this reference, you would be throwing away your teammate's work, so yes, it will be integrated into your branch).
When you do the pull request to master, it will not show those 5 files as new, github keeps track of when files are added and won't duplicate the addition. However, it will show those 5 files added to your branch in a commit.
So, tl;dr - before doing a pull request, always pull from the master branch (or the branch you'll be merging to), integrate any changes into your own branch, test your branch again, commit those changes, and then do the pull request. Any files that were already in master (like the 5 that weren't conflicting) will not be added again.
Hope this was helpful!
Dr. Dana W thanks for the detailed explanation. That was really helpful.
Thank you Dr. Dana
Wait is this video only about fixing merge conflicts with scripts? How about if there are merge conflicts with scenes in unity?
Unfortunately, it is very difficult to correctly merge scene files unless the changes were minor. Scene files can be stored as text files, but in my experience, it is easier for the team to coordinate changes to scenes and prefabs instead of trying to merge them. It is very difficult to make sure the merge is correct and all the guids are referenced correctly. Since these videos were created specifically for my students, I encourage them to avoid merging scenes and prefabs as the process is error prone.
However, take a look at the scene file in your favorite text editor (like notepad++) and you'll see the data is stored in the yaml format. Unity describes this format and the codes for various objects in their documentation. docs.unity3d.com/Manual/TextSceneFormat.html
You also have to enable this setting in the editor's project settings.
@@DrDana ok thanks for the tip ma'am.
thank you
Thank you Dana, this was exactly what I needed to learn today! Take care!
cbmira01yt so glad that it helped you!
Very useful video👍👍
Very helpful👌
Great! thanks
thankyou so much
Thanks
Please add more cpp debugging sessios
That's a great suggestion, thanks!!
AWESOME....
Great to hear that! Glad you found it useful!
Nice
Four minutes into the video, she tells you that she’s not using sourcetree to do the merge.👎👎👎👎
I'm sorry for any confusion! I tried to be clear in the title by putting VS first indicating that I'd be using VS as the primary merge conflict handling tool.
However, at least at the time, Sourcetree did not have a built-in diff tool (usually requiring kdiff or some other external diff tool integration - but even kdiff doesn't compile the code!). I elected to use VS as my external diff tool and encourage others to do the same.
VS is the best merging/diff tool since it not only works the same as any other diff tool (3 split panels - mine, theirs, and merged), but it also can show you whether the code can be compiled or not - a feature few (if any) diff tools provide! This is why I use VS for merge conflicts.