This will be the new HEAD.Ĭommit Merge branch feature-branch on the repo Git history will look like Merge branch feature-branch. When using Merge pull request, (assuming that nothing has been merged into master previously) commits 3 and 4 will be added to the master branch as a commit, which we will call Merge branch feature-branch. After doing some work, we’ll have 2 additional commits Three and Four in which we want to merge into master. To work on a new feature, we’ll branch off of master branch and create a new branch called feature-branch. So for example, we have a base master branch with an initial commit and 2 new commits, the new commits are One and Two. The default option Merge pull request on Github will take all commits from the pull request and add them to the master branch with a new commit in a merge commit. We can apply this way of thinking when we want to keep the master branch Git history clean and helpful to future you and other developers who may be combing through the history to figure out why the code structure is the way it is. Merging with a merge commit, squash merging, and “Rebase & Merge” should be pretty familiar as these are commands that are already commonly used when working on dev branches to keep commits on PRs tidy. GitHub provides three options when merging in commits, these three options being: Keeping a clean git history can save a lot of time when trying to track down commits related to a bug or issue that is disrupting dev efforts.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |