Who resolves conflicts? You or the one who approves the Pull Request?
Here's what I understand:
When I merge my changes into "master," it's generally a seamless process. However, if another developer has been working on the same file in a different branch and goes to merge his changes into "master," at that point there's a potential problem. Reason being is that unless you manually inspect the changes that were made by both developers, you wind up potentially overwriting the work of one developer with the efforts of another.
I recently uploaded some work to my team's Github. There are some "conflicts" that need to be resolved.
Do I take care of that or do the others who approved the changes resolve the conflicts?
I made a copy of the work that I did and then did a "rebase" with the newest version of my base branch and I was able to see the same conflicts on my local box. Assuming this is what my team lead is going to have to sort through, am I not doing my due diligence by breaking out a difftool and attempting to resolve some of these conflicts myself?
It may very well be foolish question, but if this is considered standard operating procedure, I'd like to tackle that before Monday.
Do you typically resolve conflicts yourself or is that reserved for those who approved the pull request?
When I merge my changes into "master," it's generally a seamless process. However, if another developer has been working on the same file in a different branch and goes to merge his changes into "master," at that point there's a potential problem. Reason being is that unless you manually inspect the changes that were made by both developers, you wind up potentially overwriting the work of one developer with the efforts of another.
I recently uploaded some work to my team's Github. There are some "conflicts" that need to be resolved.
Do I take care of that or do the others who approved the changes resolve the conflicts?
I made a copy of the work that I did and then did a "rebase" with the newest version of my base branch and I was able to see the same conflicts on my local box. Assuming this is what my team lead is going to have to sort through, am I not doing my due diligence by breaking out a difftool and attempting to resolve some of these conflicts myself?
It may very well be foolish question, but if this is considered standard operating procedure, I'd like to tackle that before Monday.
Do you typically resolve conflicts yourself or is that reserved for those who approved the pull request?
Last Comment
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Git
Git is a version control system for software development. It is a distributed revision control system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed for Linux kernel development. As with most other distributed version control systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server.
476
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
ASKER
That makes sense. In other words, I'm doing my best to remove the conflicts that I can see based on the work I'm doing and how it compares to the collective "master" on my box and then I push it. Do the pull request a that point knowing that I've done my due diligence.
As a rule though, I'm going to pull and merge things on my own on my box to make sure I'm not making more work for someone else once it gets up to Github.
Thanks!