Git with the Program: Managing Pull Requests
Git workflow is an important part of any web development team’s collaboration. Perhaps the most challenging aspect of this workflow is the process of merging git pull requests. During our ninth week at The Iron Yard Houston, our instructor, Jesse Wolgamott, assigned a weeklong group project and titled the whole week Agency Week. Our assignment was to create a music playing app that allowed users to follow certain artists, create playlists, search by genre, etc. Please note that the front-end template was provided for us. After all, we were focusing on back-end developing at the time. In the end, the eleven of us actually completed this web app.
Undoubtedly, the biggest challenge we had as a team was figuring out to manage version control on Github. All of us had been working with git and github throughout the entirety of our cohort. Adding, writing consistent commit messages, and pushing to origin master were all parts of our coding repertoire. The knowledge we lacked was what to do when our individual branches differed from the master. Unfortunately, we didn’t realize we all had issues with these merges until the second day of agency week when we saw that some of our files had these ugly sets of “<<<<<<<<< HEAD” and “<<<<<<<<<<master” lines in the code.
As a team, we figured out the process for merging the requests, which are broken down below. These steps assume that you are working on a branch on local git branch, that you have written tests using Travis-CI for the major features at the very least, and that Github has told you there are merge conflicts between yourbranch origin and origin master. The quoted lines are command line inputs.
- “git checkout master”
- “git fetch origin” — Fetches the git file stored on github
- “git checkout -b yourbranch origin/yourbranch” — switches to your branch and merges yourbranch’s local version with origin yourbranch
- “git merge master” — attempts merges yourbranch with master
- If there are auto-merging conflicts, the command line will display: “Auto-merging ‘filename’ CONFLICT(content): Merge conflict in ‘filename’”
- Go to that file in your viewer
- Find the lines that include <<<<<<<<HEAD and <<<<<<<master
- Make the appropriate changes that preserve the functionality of the master copy and still incorporate your changes
- Don’t forget to remove the <<<<<<<<HEAD and <<<<<<<<master lines as well.
- “git add filename”
- Wash, rinse & repeat 6–10 for each of the files that step 5 told you had merge conflicts.
- “git commit -m ‘fix merge’” — commits changes to yourbranch
- “git merge master” — should avoid not have any merge conflicts this time, if you still do, go back to step 5.
- “git push origin yourbranch”
- Go to github and create a new pull request
- See if all the Travis-CI tests pass. If they do, then move forward to step 17. If not, go back to your local files and fix what you need for the tests to pass.
- Explain all your changes in the code to another team member.
- Get this other team member to merge the pull request.
That seems like a lot of steps, but the process feels short when you are actually going through them. Knowledge of how to actually merge these branches correctly will make a developer a great collaborator. After our Agency Week was completely over with, this git collaboration was one of my biggest takeaways. With my first dev job starting today, I felt a certain level of confidence knowing that I had at least seen these git merging challenges before. Hopefully, any mistakes I do make will be easier to recover from with this experience under my belt.