My Git Pull Request Strategy


When working with GIT it is usually pretty simple when there aren't other people involved. You commit your changes as you go and push to the remote repository as needed with little concern for merge conflicts. 

When working with a team on a large application there are tickets being assigned, changes being made by different people and if there is not a strategy in place to avoid unnecessary headaches you might spend part of your day fixing merge conflicts instead of submitting a PR and moving on to the next priorty ticket.

There are different strategies that developers can use to ensure a smooth PR process and this is the strategy that has worked will for me. When working with an IDE like Visual Studio the GIT integration makes this process easy but to make the steps apply more universally I'll use the command line in this post.

1. Clone the main (master) repo to local. In your development environment or from a command line window run the command 'git clone <repository url>'. The URL can be retrieved from GitHub by finding the repo you wish to clone, click the Code dropdown and copy the provided URL to the clipboard. This command will save the repo to your local files. If you already have main cloned to local you can run 'git fetch' from command and this will fetch any changes that have been made since your last pull. After viewing the incoming changes run 'git pull' to integrate those changes into your local repo. In either scenario you should now have local main up to date and ready to work with.

2.  Now it's time to create your working branch. With a fresh version of main you can create a new working branch by running 'git checkout -b <working branch name>'. This will create a new branch and check into it at the same time.

3. Make the necessary code changes.

4. After making the changes or implementing the feature you're ready to PR into remote main. This is where things can get hairy. After finishing my changes the first thing I'll do is make sure all changes are committed on the working branch with 'git commit -m <brief summary of  commit>'. 

5. Next checkout main by running 'git checkout main'. This will take you back to local main where you will make sure you are up to date with any changes that have ocurred since your last pull. Run 'git fetch' to see what other changes have been made to the remote main and then 'git pull' to integrate those changes into local.

6. Now that you are completely up to date navigate back to your working branch by running 'git checkout <working branch name>'. When you are in your working branch run 'git merge main' to merge any new changes from main into your working branch. This is where there could be merge conflicts but it's okay because this approach give you the chance to solve these conflicts locally before pushing the PR. I won't go into resolving merge conflicts for now so assuming the merge was successful you have now merged all remote changes into your local and are ready to push the PR knowing that you won't be introducing merge conflicts or errors.

7. Lastly we will commit one last time to ensure any changes brought in from main are commited. After committing run 'git push origin <working branch name>'. This pull push your local branch to remote and you can use whatever ticket management system you work with to finish creating the pull request.

Thank you for reading and happy coding!

Git Pull Request Development

Written by Brian McGaw

10/25/2024

Comments

No comments yet.