Fast-forward, merge commit or merge to working tree, which is the right option to pick here?
I have a GIT repository with two branch master and entidades. I need to merge to master branch a few things from entidades branch. Take a look at image, the folder marked EntityBundle is the only thing I need to merge from entidades to master, how I do that? I hit merge on entidades branch at SmartGit and get a message like image shows but here I get lost since I don't know what is the right choice in order to no mess the master repo, can any give me a tip?
** Representation of diagram in my tool**
Answer
I'm going to assume your history looks something like this:
* A (master, origin/master)
|
| * B (entidades, origin/entidades)
| |
< some number of commits on either branch>
| |
|/
* D
(newer commits are on the top of that diagram, older on the bottom) In other words, entidades diverged from master some time ago, and you want to choose between these options. You should learn how to display / view such diagrams in your tool: they'll help you understand both what the current history looks like, and what your changes to it would do. (Such a digram might clarify your question.)
I'm also assuming you're merging entidades into master. (Your screenshot seems to confirm this.)
Now, your options:
Merge
A merge simply creates a commit that unifies the state of two branches. (Causes them to be same.) It would look like this:
* M (master)
|\
* | A (origin/master)
| |
| * B (entidades, origin/entidades)
| |
< some number of commits on either branch>
| |
|/
* D
Then, you'd likely push master to origin. Typically, if you're done working on entidades (e.g., it was a feature branch, and the feature is now merged into master), you would also delete that branch both locally and from the remote.
One of your other options, Merge to Working Tree, I think, would perform the merge, but leave the result uncommitted. If this is what it does, if you then do a git commit, you'd end up at exactly the same point as Create Merge Commit; the former option just gives you an opportunity to edit the commit.
Rebase
A rebase of entidades onto master would look something like this:
* B´ (entidades)
|
< the commits made to entidades >
|
* A (master, origin/master)
|
| * B (origin/entidades)
| |
< some number of commits on either branch>
| |
|/
* D
As I've shown it, entidades was originally "based off of" commit D, because that is where it diverged from master; the changes you made are "based" on that point. rebase here will change it to be based off of commit A. We have changed the branch's "base", or "rebased" it.
Rebasing changes history. You can see this here, in that entidades and origin/entidades have diverged: they both have commits unique to themselves. entidades has commits D..B´, whereas origin/entidades has commits D..B.
Rebasing is typically "socially acceptable" if you haven't pushed the branch, because then you're the only one that can tell that history was ever changed. However, once you've pushed changes to some remote, other people could be basing their changes off the original entidades: they would notice your history re-writing. The recommended advice is thus to not rebase things that have been pushed, since this can mess with people. (Anyone who has made changes or branches to entidades would separately need to also rebase their changes, and this can be a tedious or just onerous process for them.)
In order to push the new entidades to origin, you would need to git push -f. (-f means "force"; you need to force it because you are re-writing history, and this is typically something you should do with care, for the reasons above.)
Note that entidades is still not merged into master; however, if it is now based on master itself (the latest commit, as opposed to some ancestor), then you could fast-forward master to entidades. Whether you want to or not is up to you.