One side effect of this is that when you import the source code using a subtree merge all of the files show up as newly added files. For instance, do a web search on this subject and you’ll get a lot of information about git submodules or subtree merges, both of which are kind of complex and are designed for the situation where you’re trying to bring in source code from an external project or library and you want to bring in more changes from that project in the future, or ship your changes back to them.
The bad news is that there are a few different ways to do it and some of them end up with a less desirable result (at least for our purposes) than others. Since a repository in Git is just a directed acyclic graph, it’s trivial to glue two graphs together and make one big graph. The good news is that Git makes this sort of thing very easy to do. However, we wanted to preserve all of the change history from each repo and have it available in the new repository. Over time we realized that there was no good reason for this arrangement and was just a general hassle and source of friction, so we decided to combine our two repositories into one repository containing both halves of the code base, with each of the old repositories in its own subdirectory. Instead, remember how simple and cheap the whole concept of branching is in Git: you can simply create a (temporary) branch and delete it once you're done.A while ago my team had code for our project spread out in two different Git repositories. However, you don't have to maneuver yourself into a detached HEAD state to deal with it. This is a perfectly valid and common use case. Rebase works by creating a temporary detached HEAD state while it runs.Īdditionally, another situation might spring to mind: what about going back in time to try out an older version of your project? For example in the context of a bug, you want to see how things worked in an older revision.Submodules are indeed checked out at specific commits instead of branches.There are a handful of situations where detached HEAD states are common: More importantly, Tower will also explicitly warn you in case you're trying to commit in such a state. In case you are using the Tower Git client, the app will prominently inform you when you're in a detached HEAD state. This means they can easily get lost once you check out a different revision or branch: not being recorded in the context of a branch, you lack the possibility to access that state easily (unless you have a brilliant memory and can remember the commit hash of that new commit.). The consequence is that when you make changes and commit them, these changes do NOT belong to any branch.
When you instead choose to check out a commit hash, Git won't do this for you. You are automatically on the newest commit of the chosen branch. Normally, when checking out a proper branch name, Git automatically moves the HEAD pointer along when you create a new commit. The HEAD pointer in Git determines your current working revision (and thereby the files that are placed in your project's working directory). This exact state - when a specific commit is checked out instead of a branch - is what's called a "detached HEAD". However, you can also provide the SHA1 hash of a specific commit instead: $ git checkout 56a4e5c08 Normally, you use a branch name to communicate with "git checkout": $ git checkout development Git then places all of that revision's files in your working copy folder. With the " git checkout" command, you determine which revision of your project you want to work on.
#Cherry pick commits to merge smartgit for free#
Download Now for Free Understanding how "checkout" works
0 kommentar(er)
