Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve explanation on how merge conflicts occur #733

Open
Maaike74 opened this issue May 2, 2020 · 1 comment
Open

Improve explanation on how merge conflicts occur #733

Maaike74 opened this issue May 2, 2020 · 1 comment
Labels
status:waiting for response

Comments

@Maaike74
Copy link

@Maaike74 Maaike74 commented May 2, 2020

Proposal:
I would like to propose to change the order of events when creating a conflict in lesson 9 – "Conflicts".
Conflicts are more likely to occur when multiple people make changes to a repository at the same time rather than in a consecutive manner without pulling the current state of the repository beforehand.

Therefore I would like to propose to change the following sentence in lesson 9:

Now let’s have the other partner make a different change to their copy without updating from GitHub:

to:

Now let’s have the other partner make a different change to their copy at the same time:"

This might give the students a better grasp of how conflicts emerge when multiple people work on a piece of software collaboratively.

@kekoziar
Copy link
Contributor

@kekoziar kekoziar commented Jul 27, 2021

@Maaike74, the way it is currently worded, it reinforces that merge conflicts often occur when the local repository isn't updated from the remote prior to pushing local changes to the remote. The workflow is pull, add, commit, push. The sentence you wish to rewrite explicitly ignores the pull step by stating "without updating from GitHub." It is this workflow (forgetting to update) which often creates the conflict. From experience, I can say that forgetting pull is the main reason I receive errors and conflicts in Git. In your rewrite, will you explicitly include the step that is ignored? By explicitly stating that they're not doing something, which results in an error, it reinforces that the thing they forgot (update the local repo) is what caused the conflict, and is something that cannot be skipped.

@kekoziar kekoziar added the status:waiting for response label Jul 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:waiting for response
Projects
None yet
Development

No branches or pull requests

2 participants