Make the pull request then.Īfter the merge of the pull request, you can delete it locally: $ git branch -d mybranchĪnd on GitHub $ git push origin :mybranch Next choose a very good commit message and push to GitHub. Now make sure only the first is pick, the rest is s: pick 00f1e76 Add first draft of the Pflichtenheft Get the latest from origin $ git checkout masterįind the merge base hash: $ git merge-base mybranch master So on GitHub, I end up doing the following for a feature branch mybranch: In git, what is the difference between merge -squash and rebase?.Something that is easy to read and understand, without digging into the code. Then you can also rewrite the commit message to something very expressive.
To keep the commit history as clean as possible, you might want to squash all your commits from the test branch into one commit in the master branch (see also: Git: To squash or not to squash?). You might have made many commits in the other branch, which should only be one commit in the master branch. Clean up the new commits by git squash.īesides KingCrunches answer, I suggest to use git checkout master Run your tests, make sure the state is as you want it. I would first make the to-be-merged branch as clean as possible. if you are not sure about rebasing operations, please refer to:.Never do operations like the following: git checkout master The only thing you need to avoid is: never use rebase on public branch, like master branch. The major benefit of rebasing is that you get a linear and much cleaner project history. Yep, when you have uppers done, all the Test branch's commits will be moved onto the head of Master branch. So the best method is we have to use rebase instead of merge (suppose, when in this time, we have solved the branch conflicts).įollowing is one simple sample, for advanced operations, please refer to git checkout master Once we solve the conflicts, or if there is no conflict, we commit and push them git commit -m 'merge test branch'īut this way will lose the changes history logged in test branch, and it would make master branch to be hard for other developers to understand the history of the project. If conflict is encountered, we can run git status to check details about the conflicts and try to solve git status Test merge before commit, avoid a fast-forward commit by -no-ff, So, when we suspect there would some conflicts, we can have following git operations: git checkout test It would "squeeze" all test commits into one merge commit on master that is to say on master branch, we can't see the all change logs of test branch. It's unsafe, because we don't know if there are any conflicts between test branch and master branch. This is a very practical question, but all the answers above are not practical. The goal in all of this is to keep my test branch updated with the things happening in master and later I could merge them back into master hoping to keep the timeline as linear as possible. Question 2: Which one of these two methods is right? What is the difference there? I am not using -rebase because from my understanding, rebase will get the changes from master and stack mine on top of that hence it could overwrite changes other people made. My work on test is done and I am ready to merge it back to master. Question 1: Is this the right approach? Other developers could have easily worked on same files as I have worked btw. I would do git pull origin master from test. Let's say work on test is taking several days and you want to continuously keep test updated with commits inside master. There are several developers who either commit to master or create other branches and later merge into master. A new branch from master is created, we call it test.
0 kommentar(er)
