githubteacher / githubteacher/github-for-developers-sept-2015
Pre-Class Questions
- 主要言語
- C
- スター
- 12
- フォーク
- 37
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
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
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
評価
この issue はまだ評価されていません。