> For the complete documentation index, see [llms.txt](https://ios-course.cornellappdev.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ios-course.cornellappdev.com/resources/textbook/git-+-github/git+.md). # Git+ In the course, we only utilized some basic functionalities of Git such as staging, committing, and pushing. However, Git is a lot more powerful than that which we will discuss in this chapter. ### Branches In the course, we mainly focused on one working branch known as `main` or `master`. When we made commits, we typically pushed them all into this one branch. When using this approach, collaborating with others was very difficult to do. If we did not fetch and pull from the main branch *before* working, we often had to deal with merge conflicts. Now, imagine if both developers are working on the same branch concurrently — a merge conflict is very likely to occur. To avoid having to deal with merge conflicts every time we push to a branch, it’s often better to create separate branches when collaborating. To create a new branch and switch to it, use the following command: ```bash git checkout -b "BRANCH_NAME" ``` ### Pull Requests **Pull requests** (also known as PRs) allows us to discuss changes that were pushed onto a branch before merging it to the base branch. Let’s look at the following scenario. Suppose we have a branch called `A` whose base branch was from `main`. We push commits and make changes to the branch `A` like how we would if it was the `main` branch. When we are ready to push these changes to the `main` branch, we can submit a pull request through GitHub to merge `A` to `main`. This allows other developers to review our code before merging it to the `main` branch. If changes need to be made, then we can push new commits to our `A` branch and request a review again. When should we create a PR? There is no right or wrong answer to this question. A PR can be a single line of code or even a thousand lines. A good rule of thumb is to create a PR if it’s important to the state #### PR Chaining A huge benefit of creating branches and making PRs is that we can chain them together. Say we have two features, A and B, that need to be implemented. We create a branch off of `main` and call it `A`. When we are done with making changes to `A`, we can create a PR to merge it to `main`. While the PR is being reviewed, we may need to work on a new feature (in this case feature B). What we can do is create a branch `B` from `A` (not `main`). Now, if we create a PR, we want to create a PR to merge `B` to `A` instead of `main`. This way, we do not have to wait for the previous PR to be reviewed. Additionally, only the changes made between `A` and `B` will be shown in the PR, making it a lot easier to review. When both PRs are approved, we want to merge in the following order: 1. Merge the PR from `A` to `main`. 2. Delete the `A` branch. The target branch in the second PR will automatically change once `A` gets deleted. 3. Merge the PR from `B` to `main`. ### Resolving Merge Conflicts There are times when we may want to merge a working branch into another without creating a PR. For example, if we are on a branch `A`, we can simply merge `main` into our branch with the following command: ```bash git merge main ``` When we run this command, we may receive merge conflicts. In other words, there are conflicts between the changes of the two branches, preventing the merge from happening. My preferred way to resolve merge conflicts is by using GitHub Desktop with Visual Studio Code (VSCode). VSCode will tell us where the conflict is occurring and allow us to resolve it quickly by clicking on “Accept Current Change” or “Accept Incoming Change”. See image below.

Resolving merge conflicts on VSCode.

Of course, we can use our code editor to resolve the merge conflicts, but it can be difficult to locate where exactly the conflict is. GitHub Desktop works seamlessly with VSCode, allowing us to easily pinpoint and resolve the conflicts. ### Undoing a Commit There are times when we may want to undo a commit, such as when we push sensitive information to a public repository. To undo a commit, we can simply use the following command ```bash git reset HEAD~2 ``` where 2 means move backwards by 2 commits (we can replace this with a number of our choice). Note that this is a soft reset meaning that staged files are not reverted back to a previous state. In other words, we keep the code that we wrote on our local repository. We can then create a new commit and then **force push** our changes to the repository: ```bash git push --force ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ios-course.cornellappdev.com/resources/textbook/git-+-github/git+.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.