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

Pre-Class Questions

Ouverte
#344 7 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
question
Langage dominant
C
Étoiles
12
Forks
37
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

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

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.