I use pull quite a bit, but only for its default behavior in repos whose configuration/branch setup is "typical". Which is a little more explicit (so less dependent on configuration details, etc.). It's basically a shorthand for git checkout my_branch (Some people seem to think this default behavior is all pull does, and that can get them into trouble.) So if you want to integrate the remote master's changes into your branch, you can do git checkout my_branch If you want to affect both, you can (see below for more on that).Īlso, you can tell git what changes to incorporate into the current branch, or if you don't specify then it will look for a configured default corresponding to the current branch. This, of course, is the point of branching - changes to one branch don't automatically affect the other. If you check out your branch and then pull, the changes will be incorporated into your branch (but not master). If you check out master and then pull, the changes you pull will be incorporated into master (but not your branch). The first thing to understand about pull is, it updates the current branch. Our good friend git checkout is the right tool for the job.What git will do depends on the exact command you issue, and also on your git configuration. The simplest thing that could possibly workĪs it turns out, we’re trying too hard. Maybe, but I think we might have our Git license revoked if we resort to such a hack. When in doubt, pull out the brute force approach? Surely we can just check out the feature branch, copy the files we need to a directory outside the repo, checkout the master branch, and then paste the files back in place. But we want to be done with this task in ten seconds, not ten minutes. Maybe we can just merge the whole branch using -squash, keep the files we want, and throw away the rest. You’re thinking of git add -interactive (which won’t work for our purposes either). We could hunt down the last commit to each of these files and feed that information to git cherry-pick, but that still seems like more work than ought to be necessary. We just want to grab these files in their current state in the feature branch and drop them into the master branch. We don’t want to have to track down all the commits related to these files. git cherry-pick wants to merge a commit - not a file - from one branch into another branch. The team has made numerous commits to the files in question. Isn’t this exactly what git cherry-pick is made for? Not so fast. This seems like it should be a simple enough task, so we start rummaging through our Git toolbox looking for just the right instrument. The code you need to grab is isolated to a handful of files, and those files don’t yet exist in the master branch. (For this example, we’ll assume mainline development occurs in the master branch.) You’re not ready to merge the entire feature branch into master just yet. Something comes up, and you need to add some of the code from that branch back into your mainline development branch. They’ve been working on the branch for several days now, and they’ve been committing changes every hour or so. Part of your team is hard at work developing a new feature in another branch.
0 Comments
Leave a Reply. |