You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use interactive rebase to merge the changes to my code to the changes made in postman because they belong together.
Describe your ideal workflow
Pull master in the local repository
Start Postman
Postman automatically loads the collection from the local repository.
Make changes to both the source code and to the Postman collection.
Postman automatically saves changes to the collection to the collection file in the local repository.
Changes to the collection file can be committed together with changes to the source code.
Describe alternatives you've considered
Pull master in the local repository
Start Postman
Import the collection from the local repository
Make changes to the source code and to the Postman collection.
Export the collection to the local repository
Commit the changes to the collection together with the changes to the source code.
The downside of this method is that it requires extreme discipline from the developer to ensure that he doesn't overwrite changes made by other developers, or that his changes are actually being committed together with the code changes.
Additional context
My main problem with Postman is that the life cycle of the source code is identical to the life cycle of the Postman Collection. However, because Postman implements its own life cycle, whatever is in Postman is (almost) always out of sync with what is in the repository. Additionally, using Postman without a GitHub integration makes it impossible to roll back both the source code as well as the Postman collection to the same point in time.
The GitHub integration addresses this to some extend, but it forces that Postman creates its own commits. So even though the commit of Postman and the commit of the Developer should have been one commit, there are now two commits, obfuscating the intent and making the general timeline in git hard to read and interpret.
There is a GitHub, GitLab, and BitBucket integration, but if you have your own Git server, you're ...
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Describe your current workflow
Describe your ideal workflow
Describe alternatives you've considered
The downside of this method is that it requires extreme discipline from the developer to ensure that he doesn't overwrite changes made by other developers, or that his changes are actually being committed together with the code changes.
Additional context
My main problem with Postman is that the life cycle of the source code is identical to the life cycle of the Postman Collection. However, because Postman implements its own life cycle, whatever is in Postman is (almost) always out of sync with what is in the repository. Additionally, using Postman without a GitHub integration makes it impossible to roll back both the source code as well as the Postman collection to the same point in time.
The GitHub integration addresses this to some extend, but it forces that Postman creates its own commits. So even though the commit of Postman and the commit of the Developer should have been one commit, there are now two commits, obfuscating the intent and making the general timeline in git hard to read and interpret.
There is a GitHub, GitLab, and BitBucket integration, but if you have your own Git server, you're ...
The text was updated successfully, but these errors were encountered: