SLIDE 1
Collaborate effjciently with git Collaborate effjciently with git - - PowerPoint PPT Presentation
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 Todays goal Use effjciently Git in medium-large scale projects
SLIDE 2
SLIDE 3
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
SLIDE 4
Today’s goal
Turn this...
3
SLIDE 5
Today’s goal
Into this!
4
SLIDE 6
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
SLIDE 7
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
add few changes prefer the −−amend option and avoid a commit, fixing the previous commit
6
SLIDE 8
Distributed Workflow Best Practices
SLIDE 9
Distributed Workflow: Maintainers
- At the upstream repo use a single master branch
- Protect the master branch so only maintainers can publish
- Do not allow force push (git push −f) to the master
branch
7
SLIDE 10
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
SLIDE 11
Rebase
A D C B E
master bug-fix
F
Before rebase
A D C B E'
master bug-fix
F'
Aħter rebase
9
SLIDE 12
Rebase
- Aħter rebase you can push your changes to your publicly
visible feature branch
- Because the history has been rewritten, push will fail
- Use git push −f <fork−repo> <feature−branch> to force
the update at the remote repo
- Submit a merge request and wait for feedback
10
SLIDE 13
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
SLIDE 14
Continuous Integration
SLIDE 15
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
SLIDE 16
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
SLIDE 17
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
SLIDE 18
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
SLIDE 19