### Push Flow (Imagine Uploading Files to the Cloud) The process of pushing involves preparing your changes, committing them with a message, and then pushing them to a remote repository such as GitHub. This is akin to uploading files to the cloud. 1. **Add Changes to the Staging Area:** ```sh git add . ``` This command adds all modified and new files to the staging area, preparing them for the next commit. 2. **Commit the Changes:** ```sh git commit -m "Your message" ``` Here, you commit the staged changes to your local repository along with a commit message that explains what has been changed. 3. **Push the Changes to the Remote Repository:** ```sh git push ``` This command uploads your committed changes to the remote repository, making them available to others or syncing with the cloud storage. ### Pull Flow (Imagine Downloading Files from the Cloud) Pulling involves fetching updates from a remote repository and merging them into your local branch. It's like downloading files from the cloud. 1. **Fetch the Latest Changes:** ```sh git fetch ``` This command downloads updates from the remote repository but doesn't merge them into your local branch. It's useful for seeing what others have done without merging those changes into your work immediately. 2. **Pull the Latest Changes:** ```sh git pull ``` This combines fetching the latest updates and merging them into your current local branch, effectively downloading and integrating the latest changes. ### Creating a New Branch To start working on a new feature or fix, you might need to create a new branch. This allows you to work on your changes independently from the main project. - **Create and Switch to a New Branch:** ```sh git checkout -b main_page ``` The `git checkout -b` command creates a new branch named `main_page` and switches you to it immediately, setting up your workspace for work on this new branch. - **Push the New Branch to GitHub (Remote Repository):** After creating and switching to your new branch, if you wish to make this new branch available remotely on GitHub, you can push it using: ```sh git push -u origin <branch-name> ``` Replace `<branch-name>` with your actual branch name, e.g., `main_page`. The `-u` flag sets the upstream for your branch, meaning future pushes or pulls for this branch can be done with `git push` or `git pull` without specifying the branch name. ### Handling Multiple PRs and Conflict Resolution #### Scenario: - Multiple contributors submit PRs to merge their branches (e.g., A branch, B branch) into the main branch. - PRs from A branch and B branch do not conflict with each other initially. - If A branch's PR is merged into the main first, B branch's PR may then have conflicts. - The merging of a new PR into the main branch can also cause conflicts in other people's local branches, especially if those branches were based on an earlier state of the main branch. #### Steps for Managing PRs and Conflicts: 1. **Switch to the Local Main Branch:** ```sh git checkout main ``` This step involves changing to the local main branch to pull the latest changes. 2. **Update Local Main with Latest Changes:** ```sh git fetch origin main git pull origin main ``` Fetch and pull the latest code from the origin's main branch to your local main branch. 3. **Switch to B Branch:** ```sh git checkout B_branch ``` Change to B branch in preparation for rebasing. 4. **Rebase B Branch on Main:** For rebasing: ```sh git rebase main ``` Start the rebase process to apply B branch's modifications on top of the main branch. Rebase B Branch onto Main (or Merge Main into Your Branch): 5. **Resolve Conflicts (if any):** Upon encountering conflicts, files in question will be highlighted. Use your Git client or command line to navigate to the conflicting file and choose to resolve conflicts. This might involve manually editing files or choosing between changes. 6. **Complete the Rebase and Push Changes:** After resolving conflicts: ```sh git add . git rebase --continue git push --force-with-lease ``` Force push is necessary after a rebase to update the remote branch with the new history. 7. **Send a Merge request** #### Additional Notes: - **Conflict Resolution in Git Clients:** Look for the option to resolve conflicts in your Git client (e.g., right-click on the highlighted file and select "Resolve Conflicts"). - **Resolving Conflicts in VS Code and IntelliJ:** - For Visual Studio Code (VS Code), search for "vscode git resolve conflicts". - For IntelliJ IDEA, search for "IntelliJ git resolve conflicts". - **Updating PRs:** If additional commits are pushed to a branch that has an open PR, the PR will automatically update with the new commits. There's no need to open a new PR. - **Handling Local Commits:** If a branch is merged and then deleted, but there are local commits not pushed, those commits will remain local. To preserve changes, always push commits before deleting the branch. ### How to Review a PR #### Assignee The assignee is the individual tasked with handling the Merge Request. This entails driving the Merge Request to its eventual merger or ensuring it meets the standards for merging. In some teams or projects, the assignee might be the developer responsible for implementing the code changes or the project manager in charge of the feature or fix. The assignee must monitor the progress of the Merge Request, resolve any merge conflicts that arise, and make necessary modifications based on feedback from reviewers. #### Reviewer The reviewer is the person or team member requested to review the changes in a Merge Request. Their role is to provide feedback, suggest improvements, and confirm that the code changes meet the project's quality standards. Reviewers are responsible for carefully examining the code modifications to ensure the new code does not introduce errors and aligns with the project's overall architecture and coding standards. Multiple reviewers can be involved in a Merge Request, which helps assess the code changes from different perspectives and enhances code quality. In the Merge Request process on GitLab, judicious use of the assignee and reviewer roles can expedite the code review process, enhance code quality, and foster collaboration and communication among the team. Such mechanisms ensure the code undergoes thorough review before merging, contributing to the project's health and stability. - **Role of the Reviewer:** The reviewer concentrates on the code, ensuring it meets the project's standards. The responsibility to resolve any conflicts lies with the individual who opened the PR. - **Reviewing PRs:** Common practice for reviewing someone else's PR includes fetching their branch locally to ensure tests pass and there are no compilation errors before thoroughly reviewing the changes. #### Steps to Review a PR 1. **Open a terminal or command prompt.** 2. **Navigate to your repository's location using the `cd` command.** For example: ```sh cd path/to/your/repo ``` 3. **Check available branches.** Before switching to a specific branch, you might want to see all available branches, including those from remote (others' branches). Use the following commands to list remote branches: ```sh git fetch --all git branch -a ``` This displays all local and remote branches, with remote branches typically shown as `remotes/origin/branch-name`. 4. **Switch to the specified branch.** If the branch already exists in your local copy, you can directly switch to it. If it's a remote branch, you first need to check it out locally. Use the command: ```sh git checkout branch-name ``` If the branch doesn't exist locally, Git will automatically check it out from the remote repository. If it's your first time checking out a remote branch locally, you might need to use: ```sh git checkout -b branch-name origin/branch-name ``` This command creates a new local branch and sets it to track the corresponding remote branch. 5. **Now you can start reviewing the code.** On this branch, you can inspect changes, run the code, and perform any necessary checks or tests. 6. **Actions after the review.** Once you've completed the code review, you can leave comments, approve, or request further changes on the Pull Request page on GitHub. 7. **Remember, when you've finished reviewing and wish to switch back to the main branch, use `git checkout main` (or `git checkout master` if your main branch is named 'master') to switch back.** These steps should assist you in switching to the branch corresponding to the Pull Request you need to review.