![]() So perhaps if you like to experiment, clone the git repository via run: in the bash shell and explore the environment how git is actually cloned within the Microsoft infrastructure Github runs on (and therefore your workflow).įor that learn how to use the gh command-line interface and create one (temporary) repository (after the other) to trigger action runs and then remove the temporary repository/ies after you have reviewed the outcome. The earlier is a javascript wrapper for these exact shell commands you were asking for (but obviously their documentation misses to share the rationale of the implementation otherwise you would not have asked for it, right?). Instead of you can just run: git clone and git fetch, git checkout. Happy coding and let the build run along! (this is done in one step with git-clone(1) for all the bootstrapping.) Which then again requires to setup the remote and clone it. When you're satisfied, push it to your remote repository. Fine for clone, but you don't want to build on that. git checkout main git merge upstream/ main When you want to share some work with the upstream maintainers you branch off main, create a feature branch. And it certainly requires to fetch this revision first.Īll those branch or tag names do just evaporate over time, they are symbolic, given the child a name to ship it but then can be overwritten any time. This is what we use a version control system for. Any of those parameters is just referencing it, and git-fetch(1) ensures it fetches it (and with it all necessary files/trees/objects). GITHUB_REF, CI_COMMIT, BUILD_REVISION, REVISION - there are many names depending on which (proprietary) platform you run it.Īt the end of the day this is a reference to a commit in git identified by the SHA1 hash, the revision. However, when we automate a build, we want to specifically ensure (assert) we can and do build a very distinct revision. a branch name) and then it's HEAD that is what I meant. Git with git-clone(1) is clever enough to already understand what I'm looking for (e.g. I often just clone a repository and I don't need to take care of fetching the correct revision because it is already there. I hope this answers your question and does not sound making fun of your question, because this is easy to miss. ![]() The later, logically more important one (work on that revision), can only be done if the repository is already cloned (bootstrapped, initialized). git-fetch(1) is the correct operation to obtain ("fetch") the specific revision that is of interest (in context of the action).īoth operations need to be done. while git-clone(1) suffices to verify the remote repository is accessible and could be cloned. Because git-fetch(1) will tell us if it worked or not. Now next job is to fetch the concrete revision that is actionable. To go on, let's assume the clone operation did not fail and succeeded, we're on the happy path here. Time involved (yes, time runs backwards). ![]() Networks involved (yes, transports do fail). Really think about distributed computer systems here. So git-clone(1) will take care to clone the actual repository (or fail with that operation), but if you think twice, the contents of the repository may have already changed while cloning it (just to give one example). While it may appear to suffice to "only" clone the git repository, you have to keep in mind that git is distributed version control.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |