This is also known as the merge base this is a concept from graph theory that applies to git as well.įor example, consider the following topology of the main and my-awesome-branch branches. In general, there may be more than one, but in many cases, you’ll only be interested in the closest one. You may ask what the common ancestor of two git branches is. What Is the Common Ancestor of Two Branches? The output of this command will show the contents of my-awesome-feature, starting at the common ancestor between main and my-awesome-feature. For example, if you open a pull request for a branch named my-awesome-feature against main, GitHub will internally perform the following diff: This notation lets you view the changes in a branch, starting at the common ancestor of both branches. In a pull request, GitHub calculates the diff between the branch and the base branch using the triple-dot notation of the git diff command. With that information, GitHub is able to check if the work is actually mergeable (that is, if there are no conflicting changes in both lines of work), and if so, produce a diff of the changes that can be reviewed by a person. How Does GitHub Compute the Contents of a Pull Request?Īs mentioned earlier, when you create a pull request, you need to specify two parameters: the branch with the work you want to integrate, and the branch you want the work to be integrated into (the base branch). The diagram above represents the scenario visually. This situation is what’s usually called a stack of pull requests. Pull request A will merge into the main development branch pull request B will build on top of A and merge into A pull request C will build on top of B and merge into B. Then, create a pull request - a process in which you need to select your new branch and a base branch (where you want your changes merged), which is typically (but not always, as you’ll see) the main development branch.īut what happens when you need to create several pull requests to complete the implementation of a given feature? In this case, you’d create, say, three pull requests: A, B, and C. Next, push the branch to the remote repository you share with your colleagues. The typical workflow when you want some changes to be reviewed is that you:
GITHUB WEB EDITOR RESOLVE CONFLICTS CODE
GitHub is designed in a way that all reviewable code must be part of a git branch.
GITHUB WEB EDITOR RESOLVE CONFLICTS HOW TO
This blog post will give you the necessary git and GitHub concepts to understand how to work with dependent (stacked) pull requests. The basic unit of reviewable code in GitHub is the pull request, but the implementation of a feature may require several pull requests. If you develop software, there’s a good chance you use a platform like GitHub to collaborate and work together on code with your team.
0 kommentar(er)
