![]() Like many great things, if you are new to Git, it takes trial and error before you can come to appreciate its power and simplicity. ![]() Hopefully in the future, GitHub considers supporting fast-forward merging like some of their competitors do.Git is a simple, elegant version control system. ![]() There is no mention about it when it comes to vanilla merges. They mention fast-forward merging a few times as a comparison or as an implementation detail after a squash, but It really surprises me that GitHub doesn't support this feature. Of git being confused because you commited your feature to an old branch that has been previously squashed onto master. One last advantage of fast-forward merging is since it simply moves commits over from the parent branch, it makes stacked PRs easier because it's merge is non destructive. While this requires a bit more effort on the developers side, I like it, and it has a lot of added benefits which stem from a good, clean git log. These go against the spirit of git and can make the PR review process slower.įorces you to put your best branch forward before a merge. I've seen PRs with commits such as "forgot this", "cleanup" etc. This allows reviewers to sign off on a commit hash, knowing that exact hash will be on the target branch.įast-forward merging doesn't allow developers to be lazy. But in environments where GPG signed commits are required and security is important, having your commits merge without any hash change is a cryptography guarantee that the commit that If it's not, then a merge commit is created.Ī "rebase and merge" works similar as well, but there is one main difference and that is that "rebase and merge" re-writes the commits causing the commit signatures to change. Simply put, if your commit history is linear, git will by default use the fast-forward strategy. This merge from origin/master to local master will never create a merge commit unless your local master was previously ahead of your origin. Run git pull on the master branch and the git client automatically fast-forward merges Most devs use a fast-forward merge every day. The result is, your branch has aĬomplete linear history with all original commits intact. As a compromise I typically will do a rebase and merge (or squash and merge if I only want one commit) but this is not a true replacement for a true fast-forward merge.Ī fast-forward merge is a type of merge where when complete, the HEAD (along with the index) is updated to point at the named commit, without creating an extra merge commit. In a corporate setting if branch protection is enabled. If you use GitHub, you can use git directly and invoke the merge but this doesn't work Today, this is simply not possible on the GitHub UI. They create an unnecessary commit that was never created and can contain the changes from multiple previous commits which also exist within the branch and this can make reverting those changes harder.īy default, git will use a fast-forward merge if possible when doing git merge. Personally, I really dislike merge commits. Fast-Forward Merge: The superior git merging strategy
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |