Timeline for Conflict resolution and merging order for the project code?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 18, 2017 at 9:42 | audit | Suggested edits | |||
| Oct 18, 2017 at 9:43 | |||||
| Oct 9, 2017 at 13:38 | vote | accept | Roman Susi | ||
| Oct 8, 2017 at 23:04 | answer | added | gnasher729 | timeline score: 1 | |
| Oct 8, 2017 at 8:45 | history | edited | Roman Susi | CC BY-SA 3.0 |
added 139 characters in body
|
| Oct 8, 2017 at 7:41 | answer | added | Ewan | timeline score: 1 | |
| Oct 8, 2017 at 5:00 | answer | added | Karl Bielefeldt | timeline score: 3 | |
| Oct 7, 2017 at 17:25 | comment | added | Roman Susi | It depends. Renaming classes, moving attributes - it does not help to "merge often" half-done refactoring, because then the code will simply not work. | |
| Oct 7, 2017 at 15:14 | comment | added | Robert Harvey | Unfortunately, it sounds like you've waited too long to merge. If you're looking for a best practice, the rule is "merge early, merge often." That said, if you planned your refactorings carefully, merge conflicts should be minimal, and it shouldn't matter which branches are merged first. | |
| Oct 7, 2017 at 11:27 | history | edited | Roman Susi | CC BY-SA 3.0 |
added 5 characters in body
|
| Oct 7, 2017 at 11:22 | history | asked | Roman Susi | CC BY-SA 3.0 |