githubteacher / githubteacher/github-for-developers-sept-2015

Pre-Class Questions

Offen
#344 7 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
question
Vorherrschende Sprache
C
Sterne
12
Forks
37
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

The following is a message that I sent to training@github.com.

Hi!

I’m looking forward to tomorrow’s developer’s workshop. I’ve been using GitHub for about 9 months, and we’ve had some rough times with it, so I’m looking to understand the system better so that we can recover from losses more quickly.

Essentially, a teammate (who hadn’t synced in a while) pushed up some changes together with outdated files and the old files overwrote the newer files. New commits were made after that and we could not back the bad merge out. So we ended up cherry-picking many lost commits over time as we kept identifying more lost work. Then it happened again with someone else’s sync (who was up to date). And then yet again. It was a rough September. ;)

Here are a few questions I have right now:
- The first bad merge we know was caused by overwriting newer files with old ones but how can that happen? Shouldn’t GH prevent that? What could have gone wrong? And, mostly importantly, how can we prevent something like that in the future?
- We sought help from GH Support with that issue, and it was suggested that “excessive cherry-picking” might have been causing some of the problems. We had only started that practice after the massive loss, so that wasn’t the main problem, but still we wonder: What is the preferred way to recover from a bad merge?
- During the recovery process, I noticed that the list of commits in my desktop app often don’t match those on github.com. Why are the changes that show in the desktop app so different than those on github.com even if I’m looking at the same branch?
- Also, why does one of my colleagues in particular do so many merges instead of just regular commits? This is the person who made both the 2nd and 3rd bad merges. He merges all the time—even if he’s newly synced and no one else is editing that day, he’ll merge again and again (almost every other commit sometimes). Overall, about 25% of his commits are merges, and that makes it very hard to track what’s going on and who’s been doing what—especially when we run into a ‘bad merge’ issue.

Any thoughts you have on these issues will be helpful and appreciated.

I’m mostly taking this training to try to understand what could have happened to our project, how to keep it from happening again, and how to fix it faster and correctly if it ever happens again.

Thanks and “see” you tomorrow,
Mary

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.