Collaborate effjciently with git Collaborate effjciently with git - PowerPoint PPT Presentation

Collaborate effjciently with git Collaborate effjciently with git GSA 2019 Manolis Surligas surligas@csd.uoc.gr Computer Science Department, University of Crete

1

Today’s goal • Use effjciently Git in medium-large scale projects • Collaborate in a professional and efgective way • Reduce managerial overhead and wasted time • Provide better soħtware 2

Today’s goal Turn this... 3

Today’s goal Into this! 4

Commit changes Commit messages rules • Use the imperative mood in the subject line • Separate subject from body with a blank line • Keep subject line to 50 characters • Capitalize the subject line • Do not end the subject with period • Wrap the body at 72 characters • Use the body to explain what and why vs. how 5

Commit changes When to commit? • Prefer small commits with reasonable amount of changes • Easier for maintainers to review • If you forgot something on the latest commit or need to commit, fixing the previous commit 6 add few changes prefer the −− amend option and avoid a

Distributed Workflow Best Practices

Distributed Workflow: Maintainers • At the upstream repo use a single master branch • Protect the master branch so only maintainers can publish branch 7 • Do not allow force push (git push − f) to the master

Distributed Workflow: Developers • Fork the upstream repo • Create a short-lived branch for a new feature or bug fix • This branch is also known as feature branch • Submit a merge request to the upstream master branch • In case of the master branch has been diverged perform a rebase, resolve possible conflicts and resubmit the merge request 8

Rebase Before rebase Aħter rebase 9 A B C D master E F bug- fi x A B C D master E' F' bug- fi x

Rebase • Aħter rebase you can push your changes to your publicly visible feature branch • Because the history has been rewritten, push will fail the update at the remote repo • Submit a merge request and wait for feedback 10 • Use git push − f <fork − repo> <feature − branch> to force

Advantages • Monotonic git history • Better progress tracking • Easier to follow • Easier to spot bugs (through git blame) • Feature branches can be easily shared with other contributors for testing and reviewing • Greatly offmoads maintainers from resolving conflicts • Developers may have better overview of the conflicts • Maintainers focus on code contents not resolving conflicts • Significantly reduces the acceptance of new features or bug fixes 11

Continuous Integration

Continuous Integration What is CI? Continuous Integration is the practice of integrating code into a shared repository and building/testing each change automatically, as early as possible - usually several times a day. (gitlab.com) 12

Continuous Integration Why your team needs a CI workflow? • Detect errors as soon as possible • With the previous mentioned workflow, avoid errors to be merged on master • QA tests 13

Gitlab CI • Gitlab provides integrated CI services • Shared runners are available with Docker support • Can use dedicated runners, using the gitlab-runner services • CI is configured by the .gitlab-ci.yml file at the top lever directory of the repo 14

Gitlab CI: Simple example The recipe below performs coding style check, build and runtime check Code available at: https://gitlab.com/surligas/hello-ci 15

Questions? 15