track of your files. - Your files (Code) are kept in some centralized place(Repo) - Anybody(*) can collaborate on your files. - Can track who did it and when - Better than having 1000s backed-up zips for a 6 month long project *- As long as they are authorized to do so
controlled by vcs. - Commit: Checkpoint of our code - Head: Latest commit on master branch. - Branch: Different development path of our project, often temporary and not to be merged with main path until finished. - Merging: Joining codes of two different branches. - Tagging: Creating checkpoints of completed development.
server - Developers commit their code in Repo, so others can see it and merge. - Commits contains whole repository, even if developers have changed only 1% of whole repository. - Server communication is required at every step
server is required. - Developers can commit their code locally, others can only see if this code is sent to server. - Faster, because server is only required when needed. - Distributed between people, servers, features. - Commits contains only changed code. Distributed VCS
Too difficult to create, update and maintain branches. - Almost non existent code review system - Unauthorized (buggy) code can (and used to) be in main branch and went in live release. - Decreasing use and community support
to commit. - Speedy to commit - Easy to create branch - Easy to review code, before it’s being merged into main branch. - More community support, more help and more tooling support.
two repositories 1. Local 2. Remote - SVN has only one repository and its always remote - SVN’s trunk becomes master branch in GIT - Server Side: GIT’s remote repository is named ORIGIN by default. - SVN can not have more than one remotes for one repository. While git can have many remotes
you have worked and have anything changed without commit - If you have changed a file or added a new file your working copy is in stating mode. - You can not update your code from origin while in Staging. - Commit the code is needed - To know status run `git status` command.
never go to server. - To send it, run git push. - After commit run git status - Ahead: You have advanced code than origin (Can push without problem) - Behind: Origin has advanced code than yours (Must pull before push)
locally. - You can have as many commits as you want. - To send commits on server, you have to push the commits. - All unpushed commits goes to server by default. - CurrentBranch’s commit goes to origin/CurrentBranch - SVN’s commit = git’s commit+push
- Requires remote repository. Atleast origin defined - Fetch: gets code from server and merge to remote branch’s copy. - e.g. NewFeature’s updates are downloaded to origin/NewFeature - Pull is fetch+merging the code to NewFeature local copy. - SVN’s update = git pull
- git checkout (-b) {branchName} - git branch {branchName} - Branch is created on same location, and created within seconds - Merging is simple* - Create and merge as many branches as you want. * As long as there are no conflicts
is copying all commit tree from X to Y - Fast-Forward vs Three Way - Fast-Forward: Work is stopped in Y and all development is done on X before merging. - Three way: Development is being done parallelly in X and Y. - So there will be different commit timelines in X and Y.
the reality. - Tree Conflicts vs File level Conflicts - Tree Conflicts: Something wrong happened in entire file or directory. - To solve it, determine required strategy of that file (tree)’s status and apply it. - Extension changed, added-deleted-moved in same timeline. - File Level Conflicts: Code changed in same location(s) of file.
- Have same code style applied for whole teams. - Pull code from desired branch before push, so there will always be fast forward merge - Merging conflicts: Communicate and apply sense.
240 - Based on GITBILT. - Master branch is read only. - Create tickets to request merge in master. - Tickets will be reviewed and until approved code will not be merged in master. - Update from master or required branch before push.
commits for review. - git push origin HEAD:refs/for/{ticketNumber} - You must have unpushed commits to send to ticket. - DEMO TIME: Create from web vs Create from command line. - Created tickets will always have ticketNumber. - While creating new ticket from command line, you must have exact one unpushed commit. - Can publish multiple commits, multiple times in an open ticket
team has a code style and it’s applied in everybody’s IDE. - Code is formatted and rearranged before commit according to that style. - Apart from admins, nobody can merge directly to master, even with tickets. - Review code thoroughly and suggest changes if applies. - Press approve before you merge, applies for your own codes as well.