This is reflected in the Commit menu item in TortoiseGit’s right click menu. We can now make some changes and commit them to the local branch. Our working directory is now the newly created branch (“branch1” in my case). In the following dialog we choose our newly created local branch and hit OK. To switch to the newly created branch we right click and pick the Switch/Checkout menu item. Unless we didn’t check the “Switch to new branch” checkbox in the Create Branch dialog our working directory is still the master branch. We then get the Create Branch dialog where we enter a name for the branch and hit OK. Given that we’ve created a local repository and added a remote to it, in my case a GitHub repository, we can create a local branch by right clicking in a directory in the repository and pick the Create Branch menu item. I therefor decided to do some research and experimentation and document a workflow that seems to work. The documentation for handling branches using the console is great, but when I’ve been using TortoiseGit I’ve often felt confused and insecure when dealing with remote branches. This means that a branch is unique to each repository and the workflow when wanting to push a local branch to a remote repository, or the opposite, is a bit different. Git makes it really easy and fast to work with branches compared to many version control systems that aren’t distributed, but coming from the world of TFS or SubVersion where a branch is basically a physical directory that one can check in and check out in Git it’s pretty much just a pointer. If you specify "HEAD" as the revision, you will restore the last committed version of the file, effectively undoing any local changes that you current have in that file: $ git checkout HEAD index.As a user of TortoiseGit I’ve always been a bit confused when it comes to dealing with remote branches. If, in one go, you also want to create a new local branch, you can use the "-b" parameter: $ git checkout -b new-branchīy using the "-track" parameter, you can use a remote branch as the basis for a new local branch this will also set up a "tracking relationship" between the two: $ git checkout -b new-branch -track origin/developĪnother use case for "checkout" is when you want to restore an old revision of a file: $ git checkout 8a7b201 index.html This will make the given branch the new HEAD branch. In its simplest (and most common) form, only the name of an existing local branch is specified: $ git checkout other-branch If you want to restore a specific earlier revision you can provide that revision's SHA-1 hash. By providing HEAD as the revision, you can restore the last committed version of a file - effectively undoing any local changes that happened since then. Restores a historic revision of a given file. when unpushed commits in the local branch or unpulled commits in the remote exist). This allows you to more easily see when the two aren't in sync (i.e. This way, the new local branch has a tracking relationship with its remote counterpart. This can be used as a shortcut instead of the following two commands:Ĭreates a new local branch - and sets up an "upstream" configuration. b Ĭreates a new local branch and directly switches to it. By specifying the name of a local branch, you will switch to this branch and make it the current "HEAD" branch.
The name of a local branch that you want to switch to. Thereby, you can reset single files to earlier revisions - while keeping the rest of the project untouched. The most common use case for "checkout" is when you want to switch to a different branch, making it the new HEAD branch.Īnother use case for "checkout" is when you want to restore a historic version of a specific file. The "checkout" command can switch the currently active branch - but it can also be used to restore files.
0 kommentar(er)
