It can also cause issues with automated test build systems that keeps the repository and just updates to the latest revision between builds. This might be easy to communicate if you’re working within a small team but becomes much harder to communicate if it’s a large team or an open source project online. This is something every developer has to do if they’ve pulled down the original commit. If you have local changes not yet pushed like in this example you would first have to move them over to the new commit using rebase before stripping the obsolete commits. To fix you would have to strip the obsolete commit. So because the “Add workspace to app” commit was modified it now has a different hash (including all descendant commits since they’re modified too to update the parent hash reference since it’s changed), so it will appear as a different commit in the commit history alongside the original commit. The reason this happens is because commits are identified by their hash number (see identifying commits for more details). If another developer were to modify the “Add workspace to app” commit and you pulled down that change, this is what it would look like on your local repository: The risk with modifying history that you have pushed is if someone else has already pulled the commits down that you plan to modify. Firstly there is no risk to modifying history on commits that you have not pushed.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |