Git Handling

Working with git submodules

SSH authentification with a key pair on GitHub is recommended: https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh. For Windows users, follow that setup guide: https://gist.github.com/dmangiarelli/1a0ae107aaa5c478c51e

Do not forget to put your public SSH key under your GitHub account.

For consistency, ensure you use SSH URIs everywhere for GitHub repositories by checking their .git/config configuration file.

Initialising

While cloning

git clone --recurse-submodules <repo-uri>

After cloning

git submodule --init --recursive --force or npm run git:sinit

Syncing URIs

Must be executed after submodule repository URI changes in the main repository .gitmodules file

git submodule sync

Updating

npm run git:supdate

Pushing including submodules

npm run git:spush

Diff including submodules

npm run git:sdiff

Workflow and codeflow

Git submodules used in a repository are shown just as a first class repository in Visual Code and are indeed like any other git repository, so you can just treat them like any other git repository

Keep submodules up to date

Most of the time, you'll just have to pull the submodules latest changes:

• Perform a git pull on the main repository
• Run the command npm run git:supdate

You can also do a git pull for each submodules repositories in the main repository one by one in Visual Code

Making changes to submodules

You'll have to keep in mind if you make changes to one submodule repository, you'll have to:

• Use a same naming for the branches in the main and the submodule repository
• Commit first your changes in the submodule repository
• Ensure the main repository reference the commit id pointing to your latest changes in the submodule repository with git diff or npm run git:sdiff
• Do two PRs: one for the main repository and one for the submodule repository

Git submodules paths in ev-server:

• src/integration/pricing/convergent-charging
• src/integration/refund/concur
• src/integration/smart-charging/sap-smart-charging
• src/assets/charging-station-templates
• src/assets/configs-aws
• src/assets/configs-scp
• src/assets/configs-ci

So, carefully handled the changes you might do in that paths

Example: You have to make changes on both ev-sap-smart-charging (ev-sap-smart-charging is a sub-module in ev-server located at src/integration/pricing/convergent-charging) and in ev-server repositories:

• Create a branch from the up to date master-qa branch in ev-server repository: <feature-name>
• Create a branch from the up to date master-qa branch in ev-sap-smart-charging repository with the same name: <feature-name>
• Do your changes that on both repositories and test them
• Commit your changes in the ev-sap-smart-charging repository first and push them in your remote branch
• Commit your changes in the ev-server repository and push them in your remote branch
• Create a PR from the branch on the ev-sap-smart-charging repository
• Create a PR from the branch on the ev-server repository

The same goes on each submodules in ev-server impacted by your changes.

Tips and tricks

Reseting submodules

git submodule foreach 'git reset --hard'

Checkout the same branch in each submodule

The targeted branch must exist.

git submodule foreach 'git checkout <branch-name>'

You get the point: git submodule foreach '<command>' allows you to run the same <command> in each submodule

Git history reset handling

Syncing with GitHub

1. Do a copy of your local repositories
2. Open a terminal or a PowerShell windows and go in the repository directory. Visual Code can do this for you automatically: Terminal -> New Terminal and choose the targeted local repository directory if needed
3. Checkout master-qa branch: type git checkout master-qa (Visual Studio can probably also do it via a GUI)
4. Type git reset --hard origin/master-qa to reset your local history index and tree in master-qa with the GitHub remote master-qa branch ones

Dealing with your local changes

In the local repositories, you will find all the local changes you've made in each of your branches. Now you want to report the changes made in your <topic-branch> on the history rewritten master-qa.

In the previously opened terminal in the targeted local repository:

1. git checkout master-qa

2. git branch -b <topic-branch-new-name>

3. git checkout <topic-branch>

4. git pull origin master-qa-old and fix eventual conflicts

5. git diff -M origin/master-qa to visualise your changes

6. If you're ok with the changes: git diff -M origin/master-qa > <topic-branch>.patch or continue editing until you're ok

7. git checkout <topic-branch-new-name>

8. git apply --ignore-space-change --ignore-whitespace <topic-branch>.patch
   If the patch doesn't apply, try:

   • on Windows: Get-Content .\<topic-branch>.patch | Set-Content -Encoding utf8 <topic-branch>-fixed.patch
   • on *nix: iconv -f ascii -t utf-8 <topic-branch>.patch -o <topic-branch>-fixed.patch
   • git apply --ignore-space-change --ignore-whitespace <topic-branch>-fixed.patch

   If it still doesn't apply, try: git apply --reject --whitespace=fix <topic-branch>.patch
   Then manually merge the rejection in *.rej files and delete them

9. rm <topic-branch>.patch

Then you can work as usual on <topic-branch-new-name> and delete your old <topic-branch>.

Repeat for each of your branches.