Merge Conflicts · Banno Docs

Dealing with Merge Conflicts

First, let’s start off with a brief explanation of what is happening when you work on a site/that site’s repo.

The repo on Github is the site’s “record.” Github stores a copy of the site’s files and a record of all the changes that were made and who made them. A “repo” is just a collection of files. What makes it a “repo” is that the collection of files is stored on Github, and we use Git commands to work with the files and keep them updated.
When you do a ‘git clone’, you are just downloading a copy of the site’s files to your machine.
Next you do your npm install, and then work on those files on your machine. When your work is done, you do a ‘git add’, ‘git commit’ and ‘git push’, then create a PR (pull request) on Github. You have to do git add/git commit/push branch every time you make changes to the repo on your machine, so that the Github repo can receive those changes. Otherwise, the changes are just sitting on your machine and can’t become part of the site’s record.
When your work is approved and ready to be pubbed to the prod site, you click the green PR button on Github, which merges your work into the Github repo, making it a part of the site’s record.
From then on forward, the next dev that works on the site will clone the repo and your changes will be there. And so on, and so forth.

When you can’t merge your changes by clicking the green button, that means that Github has recognized that the contents of your PR do not match up with what’s in the repo that is on Github. This usually happens because another dev made changes to the site’s repo on Github after you created your PR. This is why we try to discourage the CWAs from having multiple cases out for the same bank.

If you notice there’s already a PR for the site you’re about to work on, the first thing you can do is to contact the CWA and ask if they can hold off on the new case until after yours goes live. Sometimes the CWA is just not aware that there’s already a case out for their bank. Or, sometimes the CWA is aware, and either they or the other dev contacts you.

In any case, if the bank just HAS to have a new case go live before yours does,

The new case should probably go to another dev because your machine may get “confused” if you are trying to work on multiple branches in the same repo after you’ve already done work.
Ask the CWA to let you know when the other case gets merged/goes live. Or ask the dev of the new case to let you know. Because that’s when you will be able to update your repo on your machine with their changes, and make your PR button turn green again.

It’s always a good idea to get some info on what work was done in the other dev’s case, just so you can check later and make sure that their work was merged successfully into your work. Like for example, if you know that the other dev added a password field to the OLB, you can check later and make sure that those changes were carried over into your PR.

After the new case goes live, and you go to your case’s PR on Github, the button will not be green anymore, and it will say there are merge conflicts.

Method 1

Open Terminal from your repo’s development folder on your machine and enter these commands one at a time.

git checkout master [or git checkout main]
git pull origin master [or git pull origin main]
git checkout case#### [fill in your case branch name]
git merge master [or git merge main]

A list of conflicts should appear. It will look like a big threatening blob of stuff at first. That’s okay!
Most conflicts will auto-merge. Github is smart enough to know which work of the other dev’s case to keep, and which work of your case to keep.
You need more details as to which files are conflicting. Type git status into Terminal and hit enter. You should then see two nice neat lists of filepaths: The ones that are auto-merging (Changes to be committed), and the ones that are in conflict. (Unmerged paths)
Most of the time, the merge conflicts are related to deploy or assets. Those filepaths will start with /deploy or src/assets. That makes sense because every time you run gulp or grunt and build the deploy zip, you change the deploy zip and hence everything that’s in the assets folder, even if you don’t make any changes to the site’s actual code. So the deploy/assets on your machine, and the deploy/assets coming from the other dev in the other case, and the deploy/assets in the main Github repo are all going to be different. Lol! The only one you need to worry about is yours though.
There are 2 ways to proceed from here:
1. If they’re all deploy and src/assets files, you’re all good, and you should just be able to gulp/grunt and continue as per usual.
  - Then do git add/git commit/git push like you would as usual. Your merge request button on your Github PR should now turn green again!
  - Don’t forget to reupload your deploy zip to UAT. You should now see both the other dev’s work and your work on UAT.
  - Now that your branch is up to date with all changes, your pull request should now be showing that you can merge it. Go back up to step 13. and follow the instructions from there.
2. If there are actual conflicts
  - You can open those conflicting files in the repo on your machine in Sublime or your favorite text editor and choose which code to keep and which code to remove. You should see obvious sections in the files, blocked off with comments that have lots of arrows and uppercase text. (Github puts those comments there.) Make your changes, including removing those comments, then save your changes like usual.
  - Or you can choose entire files by line command in Terminal. Run both of these commands, one at a time:
```
git checkout --ours filepath
git add filepath
```
  - This basically tells Github “keep my file” or “keep their file.”
  - If you need to keep “their” file(s) just change –ours to –theirs.
  - You can just copy/paste from the conflicting files list in Terminal to get the filepath(s) you need.
  - Repeat the two commands (git checkout –ours [filepath] and git add [filepath]) for every individual conflicting file.
  - After you’re all done, run gulp/grunt so you can have a new deploy with all changes incorporated.
  - Don’t forget to reupload your deploy zip to UAT. You should now see both the other dev’s work and your work on UAT.
  - Now that your branch is up to date with all changes, your pull request should now be showing that you can merge it. Go back up to step 13. and follow the instructions from there.

Method 2

If the case comes back to you for publish, and there HAS been other work done and merged since you created your branch (usually indicated by the “Merge Pull Request” being grayed out along with a notice that there are merge conflicts), while in your branch run:

git pull origin master

That command is asking for any changes that might have been merged to the master after you created your branch. Some changed files will go ahead and auto merge for you. However, you might see other merge conflicts. Most of these will be in the deploy or assets folder and can be ignored. Any files that did not auto merge AND are not part of the build files will need to be reviewed with your text editor to see what change should take precedent. You’ll see it marked with something like this.

	<<<<<< HEAD  
	Code 1  
	\=======  
	Code 2  
	\>\>\>\>\>\>\> \#\#\#\#\#\#

Manually change the html in this conflicting file/code to only show the code that should be there.
Run gulp or grunt to rebuild the deploy. You will want to upload this new deploy zip to UAT just to make sure everything still looks okay and you still have no console errors. This is especially important if you did have to manually fix conflicts.
If all looks good, you will proceed with the regular process. Add, commit, and push your branch. Your message here could be something like “updated branch with master changes to push live”

git add -A
git commit -m "updated branch with master changes to push live"
git push origin case123456

Now that your branch is up to date with all changes, your pull request should now be showing that you can merge it. Go back up to step 13. and follow the instructions from there.