This is one of the parts that have confused me the most. In the following Push dialog we simply hit OK. To do this we use the Push right click menu option just like we would have if we were working in the master branch. To me this is slightly confusing as pushing it doesn’t mean pushing that actual branch to the remote repository but rather creating a new branch in the remote repository and pushing the changes. When we want to share our local branch with others, or store it in a remote repository to back it up or be able to retrieve it from another computer we need to push. Pushing the local branch to a new remote branch (on GitHub) 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. This will perform a fetch and merge of remote commits.As a user of TortoiseGit I’ve always been a bit confused when it comes to dealing with remote branches. To get up-to-date (merge) with your own branch just pull on it to get the latest changes. Your branch locally will be "behind" as there are changes proposed by others that you haven't synced with yet. When someone else pulls into your feature branch 112-fix-buffer and makes changes then pushes those changes. Let's say we had a feature branch named 112-fix-buffer that we submitted some changes on in a public repository called the-buffer-proj. Now you have a local copy of the changes in a upstream feature branch, its time to start revewing and approve or reject those changes! If you want to see what branch your currently on, use git branch. Then switch branches into the feature branch with git checkout. The following usage would be: git fetch upstream pull/25/head:323-fix-async Lets say there was a pull request with id equaling 25 and the branch this PR was submitted from is 323-fix-async. git fetch upstream pull/id/head:$BRANCHNAME If your pulling into a feature branch from a remote repository, use upstream instead of origin. Fetch changes from a local or remote feature branch and switch branches to the newly created branch from the fetch. git fetch origin pull/2/head:563-some-bug-fix We fetch the changes from a specific feature branch and then can use git checkout to switch branches into the feature branch. git fetch origin pull/id/head:$BRANCHNAME Turns out it was really quite simple, but we need to specify an associated pull request ID when fetching the remote branch. It seemed straightforward, fetch changes from an upstream branch and checkout your own local branch with those fetched changes. Before I knew the git commands to accomplish pulling into a feature branch, I tried thinking about how I would actually get the changes from a remote branch. I saw this phrase appear again and again while contributing to Open Source. When reviewing a PR, its usually helpful to pull into that feature branch and test the changes locally in your own copy of the project.Ĭan you pull into my feature branch and review the changes locally?
0 kommentar(er)
