Git Basi, workflow e concetti avanzati (pt2)

Size: px

Start display at page:

Download "Git Basi, workflow e concetti avanzati (pt2)"

Russell Richard
5 years ago
Views:

1 Git Basi, workflow e concetti avanzati (pt2) Andrea Fornaia, Ph.D. Department of Mathema.cs and Computer Science University of Catania Viale A.Doria, Catania Italy fornaia@dmi.unict.it hfp://

2 Go Remote

3 Working with Remotes remote repository pull fetch push local repository commit index (stage area) checkout HEAD working directory add

4 Extend Basic Commands Checkout a branch (master) git checkout <branch name> Change some files See what you've changed git status git diff git log git blame <filename> Indicate what changes to save git add git rm git mv Commit those changes to local repo git commit Push the changes to remote repo (e.g. GitHub or BitBucket) git push Pull changes from your collaborator git pull git fetch

5 Cloning an Existing Repository If you want to get a copy of an existing Git repository, for example, a project you d like to contribute to, type: $ git clone What does it do? Creates a directory named project_name Ini.alizes a.git directory inside it Pulls down all the data for that repository Checks out a working copy of the latest version (HEAD) Default breanch is master Support different transfer protocols - (https) - user@server:path/to/repo.git (ssh)

6 BitBucket Hosts free and professional private git repositories ( SourceTree desktop client can be used for any git and mercurial repository

7 Create a private repository on BitBucket Register Repositories > Create Repository

9 Other solutions

10 Remotes Collaborating with others involves managing remote repositories origin is the server you cloned from You can have different remotes # list remotes (-v for verbose output, include urls) $ git remote v origin Connect a local initialised repository to remote server $ git init $ git remote add origin

11 Remote and Local branches branch- to- upstream mapping master teamone/master master tracks the remote branch teamone/master $ git branch v # list local branches * master a366c90 C7 $ git branch v --all # list all branches * master a366c90 C7 remotes/teamone/master b786a41 C6 $ git branch -v # branch-to-upstream mapping * master a366c90 [teamone/master] C7 # (remote-tracked branch)

12 Git fetch Remote Local Local aaer fetch master C7 C4 master origin/ master C7 C4 master C6 C3 C6 C3 C2 C2 C2 C1 C1 C1

13 Git fetch Downloads commits, files, and refs (branches) from a remote repository into your local repo See everybody else (pushed) work Doesn t force you to actually merge the changes into your repo Remember: git stores all commits, local and remote $ git fetch <remote>

14 Git pull = fetch + merge origin/ master Local aaer fetch C7 C4 master origin/ master Local aaer merge C8 C7 C4 master C6 C3 C2 C6 C3 C2 C1 C1

15 Git pull Fetch content from a remote repository and automatically merge changes only into working branch: Merges a remote branch into a local branch $ git pull <remote> Same as a (clearer and safer) fetch & merge $ git fetch <remote> $ git merge <remote>/<working-branch-name> Try to use fetch & merge instead of pull In case of problem it s often difficult to work out the reason

16 Git push = remote ff merge Local aaer pull Local and Remote aaer push C8 master C8 master origin/ master origin/ master C7 C6 C4 C3 C7 C6 C4 C3 if fast forward merge is not possible push is refused (pull required) C2 C2 C1 C1

17 Git push Upload local repository content to a remote repository $ git push <remote> <branch> This creates or update the branch in the remote repository Merge a local branch into a remote branch Git won t let you push when it results in a nonfast-forward merge in the destination repository Prevents you from overwriting commits To solve the problem, update the branch content with either pull or fetch & merge

ons Tip: C6 and C7 are merge commits Tip: for each non- merge commit simply create a file as C1.txt, C2.

18 Exercise: dealing with remotes One Remote: create a repository hosted by BitBucket, GitHub or GitLab (your choice) Two Locals: clone the remote twice (separate dirs) to simulate concurrent modifica.ons Tip: C6 and C7 are merge commits Tip: for each non- merge commit simply create a file as C1.txt, C2.txt Tip: to ease reading, use simple commit message as C1, C2 C7 Tip: use git remote rename origin teamone to rename remote Tip: use git log - - graph - - decorate - - all - - oneline to see logs

19 Solution $ git clone clone1 $ git clone clone2 $ cd clone1 $ touch C1.txt && git add C1.txt && git commit -m C1 $ git push $ cd../clone2 $ git pull $ touch C2.txt && git add C2.txt && git commit -m C2 $ touch C3.txt && git add C3.txt && git commit -m C3 $ cd../clone1 $ git checkout -b C5br $ touch C5.txt && git add C5.txt && git commit -m C5 $ git checkout master $ touch C4.txt && git add C4.txt && git commit -m C4 $ git merge C5br m C6 $ git branch -d C5br $ git push $ cd../clone2 $ git fetch $ git merge origin/master m C7 $ git remote rename origin teamone

20 Advanced Workflows

21 Gitflow master: always reflects a produc'on- ready state. Only has tags tags: to mark produc.on ready releases develop: latest delivered changes for next release (integra.on branch) feature branch: to develop a single new feature. May exist in developer repos only, not in origin release branch: (e.g. release- 1.2) to prepare develop content for next produc.on release holix branch: (e.g. hogix ) when a cri.cal bug in a produc.on version must be resolved immediately

22 Git Flow setup in SourceTree

23 Other well known workflows Central Repository For who comes from CVCS (like SVN) Local changes are made on master branch In case of conflicts while pushing, use rebase Produces a linear history Feature Branching Use only one long-running branch (master) Use topic branches to develop new features of fixes Use tags to mark production ready releases Is easier then gitflow, you could start from this! Forking Workflow Each contributor (or group) refers to two git repositories: a private one and a public (official) one Developer pushes to their own private (server-side) repository Only the project maintainer can push to the official repository (handling developer s pull requests)

24 Forking Workflow dev1 private repo fork maintainer public repo fork dev2 privaterepo push push push dev1 local repo mainteiner local repo dev2 local repo commit commit commit

25 Create the Workflow for your needs GitHub repository official repo pull push tespng repo Server with GPU pull development repo Laptop with IDE & refactoring tools

26 SCM & Pipelines

27 Branches and Environments Note: example with feature branching workflow [hfps://blog.kontena.io/con.nuous- delivery- with- gitlabci/]

test: stage: test script: - apt-get update -qy - apt-get install -y nodejs - bundle install --path /cache - bundle exec rake db:create RAILS_ENV=test - bundle exec rake test staging: stage: deploy

28 test: stage: test script: - apt-get update -qy - apt-get install -y nodejs - bundle install --path /cache - bundle exec rake db:create RAILS_ENV=test - bundle exec rake test staging: stage: deploy script: - gem install dpl - dpl --provider=heroku --app=gitlab-ci-ruby-teststaging --api-key=$heroku_staging_api_key only: - master GitLab Pipelines push code developer repository pipeline triggered production: stage: deploy script: - gem install dpl - dpl --provider=heroku --app=gitlab-ci-ruby-testprod --api-key= $HEROKU_PRODUCTION_API_KEY only: - tags when: manual.gitlab- ci.yml if commit on master run jobs staging runner producpon if tagged commit [hfps://gitlab.com/help/ci/examples/test- and- deploy- ruby- applica.on- to- heroku.md]

29 Typical Pipeline [hfps:// delivery- with- gitlab- ci- and- ansible- part- 2/]

30 Travis

31 .travis.yml language: python python: - "2.7" - "3.4" # command to install dependencies install: - pip install -r requirements.txt # command to run tests script: - pytest deploy: provider: heroku api_key: master:... production:... app: master: my-app-staging production: my-app-production [hfps://travis- ci.com]

GETTING TO KNOW GIT: PART II JUSTIN ELLIOTT PENN STATE UNIVERSITY

GETTING TO KNOW GIT: PART II JUSTIN ELLIOTT PENN STATE UNIVERSITY 1 REVERTING CHANGES 2 REVERTING CHANGES Change local files git reset git checkout Revert a commit in the branch history git revert Reset