Image NASA Remote repositories Exercise 5 Remote repositories

Image: NASA Remote repositories (Exercise 5)

Remote repositories • git repositories are usually hosted on a server (with or without web interface) • Users then copy that code repository to work on it locally • The git server is a “remote“ for their local repository https: //medium. com/swlh/continuous-integration-with-arduino-ce 3714 c 19 b 44 C 2 SM 2

Remote repositories • When you copy a repository from a server to your local workspace, git will automatically connect the two repositories • The remote repository is named “origin“ by git origin https: //medium. com/swlh/continuous-integration-with-arduino-ce 3714 c 19 b 44 C 2 SM 3

Remote repositories • Remotes don‘t have to be web-hosted • Can have multiple remote repositories https: //east. fm/refcards/git/syncing. html C 2 SM 4

Remote branches • Your local repository will have local branches AND remote branches • You can set up local branches to track the remote ones https: //www. toolsqa. com/git-create-branch/ C 2 SM 5

Exchanging code with remote repositories https: //salesforcecodex. com/salesforce/useful-git-commands/ C 2 SM 6

Exchanging code with remote repositories git pull = git fetch + git merge https: //salesforcecodex. com/salesforce/useful-git-commands/ C 2 SM 7

Image: NASA Repository managers (Exercise 6)

Repository managers • • Interfaces for git repositories Can use the web service or install locally Pricing varies- check for academic discounts! Examples: • C 2 SM hosts software on Github web interface • EMPA and IAC use Gitlab local server C 2 SM 9

Repository manager features • Easily examine commits and files • Collaboration tools (more later!) • Issue reporting • Code review • Merge requests • Automation of testing C 2 SM 10

Single user or small group workflow https: //trailhead. salesforce. com/en/content/learn/v/projects/develop-app-with-salesforce-cli-and-source-control/addsalesforce-dx-project-to-source-control C 2 SM 11

Large group workflow: using forks http: //www. programmersought. com/article/4701192164/ C 2 SM 12

Image: NASA Workflow example: COSMO (Exercise 7)

• Code under active development • More than a hundred users in the C 2 SM community • Hosted on Github for more than 5 years C 2 SM 14

Workflow summary: Make a fork Make a feature branch Develop the feature Make a pull request Test the code Code review and merge C 2 SM 15

Pull requests • Merge request on the repository manager • Add a description and important information • Use labels to give repository users information C 2 SM 16

Testing • Automated testing systems can be integrated into web interfaces • Developer must fix failing tests themselves • We have a C 2 SM Jenkins for members to use C 2 SM 17

Code review • Request a code review on the web interface • Designated reviewer can comment line by line • Reviewer can accept code as is or request changes C 2 SM 18

Merging pull requests • Code administrator can merge code and close pull request • Use squash merge to reduce number of commits • Immediately delete feature branch after pull request is closed (remotely and locally!) https: //backlog. com/git-tutorial/rewriting-history/ C 2 SM 19

Tracking issues • • • Can be used for bugs, feature requests, or questions Can add descriptions, labels, and assignments Issues can be closed by mentioning in a pull request C 2 SM 20

Workflow best practices: 1. Choose a workflow at the beginning of the project 2. Whenever possible, put your developments back into the main branch 3. Protect the main branch from accidental code pushes (branch management on repository manager) 4. Keep your branches clean and small: one feature per branch. 5. Test the code regularly C 2 SM 21