Git

version-control

https://github.com/angular/quickstart/blob/master/README.md

Articles
Resources
Videos
GUI tools
Git versus Subversion
Git for Subversion users

Github
Getting Started
Patching
Commands
Miscellaneous

Tutorial
Cheat sheet
Installation
Create an empty repository
Configurations
Version
Cloning an existing repository
Adding files
Displaying log messages
Ignore files
Branching and merging
Push & pull
Stash
Managing remote repositories
Getting help
Staging area
Hooks

git diff // show the changes that we have made to our file

What are the things that I can put on GitHub?

  1. My jQuery tooltip plugin
  2. Develop the tts browser extension or Wordpress plugin, and submit it to the Wordpress plugin directory as well.

What are the git commands?

What are the differences between distributed and centralized version control?

Distributed revision control (DRCS) takes a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer’s working copy of the codebase is a bona-fide repository. Distributed revision control conducts synchronization by exchanging patches (change-sets) from peer to peer. This results in some important differences from a centralized system:

  1. No canonical, reference copy of the codebase exists by default; only working copies.
  2. Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server. Communication is only necessary when pushing or pulling changes to or from other peers.
  3. Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing natural protection against data loss.
  4. In DVCS there may be many “central” repositories. Code from disparate repositories is merged based on a web of trust, i.e., historical merit or quality of changes.
  5. Numerous different development models are possible, such as development / release branches or a Commander / Lieutenant model, allowing for efficient delegation of topical developments in very large projects. Lieutenants are project members who have the power to dynamically decide which branches to merge.
  6. Network is not involved in most operations.
  7. A separate set of “sync” operations are available for committing or receiving changes with remote repositories.

In a distributed VCS like Git every user has a complete copy of the repository data stored locally, thereby making access to file history extremely fast, as well as allowing full functionality when disconnected from the network. It also means every user has a complete backup of the repository. Have 20 users? You probably have more than 20 complete backups of the repository as some users tend to keep more than one repository for the same project. If any repository is lost due to system failure only the changes which were unique to that repository are lost. If users frequently push and fetch changes with each other this tends to be a small amount of loss, if any.

In a centralized VCS like Subversion only the central repository has the complete history. This means that users must communicate over the network with the central repository to obtain history about a file. Backups must be maintained independently of the VCS. If the central repository is lost due to system failure it must be restored from backup and changes since that last backup are likely to be lost. Depending on the backup policies in place this could be several human-weeks worth of work.

Due to being distributed, you inherently do not have to give commit access to other people in order for them to use the versioning features. Instead, you decide when to merge what from whom. That is, because subversion controls access, in order for daily checkins to be allowed – for example – the user requires commit access. In git, users are able to have version control of their own work while the source is controlled by the repo owner.

Branches in Git are a core concept used every day by every user. In Subversion they are more cumbersome and often used sparingly. The reason branches are so core in Git is every developer’s working directory is itself a branch. Even if two developers are modifying two different unrelated files at the same time it’s easy to view these two different working directories as different branches stemming from the same common base revision of the project.

What are the advantages of distributed version control?

  1. Allows users to work productively even when not connected to a network
  2. Makes most operations much faster since no network is involved
  3. Allows participation in projects without requiring permissions from project authorities, and thus arguably better fosters culture of meritocracy instead of requiring “committer” status
  4. Allows private work, so users can use their revision control system even for early drafts they do not want to publish
  5. Avoids relying on a single physical machine as a single point of failure.
  6. Still permits centralized control of the “release version” of the project

What are the disadvantages of distributed version control?

  1. As a disadvantage of DVCS, one could note that initial cloning of a repository is slower compared to centralized checkout, because all branches and revision history are copied. This may be relevant if access speed is low and the project is large enough.
  2. Another problem with DVCS is the lack of locking mechanisms that is part of most centralized VCS and still plays an important role when it comes to non-mergable binary files such as graphic assets.

What are some key differences between Git and Subversion?

Git has a staging environment where you can commit your changes but your change is not push or pull into the "release branch". You have to do that separately.

How can we get Git to work more like Subversion?

Git can work with the same workflow as Subversion, with a group of developers using a single repository for exchange of their work. The only change is that their changes aren't submitted automatically but they have to push (however, you can setup a post-commit hook that will push for you every time you commit; that loses the flexibility to fix up a screwed commit, though). The developers must have either an entry in htaccess (for HTTP DAV) or a UNIX account (for SSH). You can restrict their shell account only to Git pushing/fetching by using the git-shell login shell. https://git-scm.com/course/svn.html

What are the 3 main states of a file?

committed, modified and staged

  1. committed: Data is securely stored in a local database
  2. modified: File has been changed but not committed to the database
  3. Flagged a file’s changed version to be committed in the next snapshot
image066.png

What is the definition of a repository in Git compared to Subversion?

In a way, a git repository is more like a branch in Subversion. Cloning a Git repository is like creating a branch in Subversion. But a cloned repository is still a repository. Within the cloned repository, we can still create branches.

What is included in the Local Repository Structure?

The local Git repository has three components:

  1. Working Directory: The actual files reside here.
  2. Index: The area used for staging
  3. Head: Points to the most recent commit
image036.png

What is the purpose of the 'get fetch' command?

Fetching entails pulling data that you don’t have from a remote project.

git fetch [remote-name]

For cloned repositories, use the command git fetch origin to pull down any new changes that were pushed to the server since you cloned or last fetched from it.

What is the difference between 'git fetch' and 'git pull'?

git fetch solely pulls new data to a local repository; it does not merge changes with or modify your local working copy. It only update the .git folder. Use the git pull command automatically do fetching and merging.

Can we push our changes to any remote repository?

No. You can only successfully push changes upstream if you have write access for the server from which you cloned, and if someone else has not pushed changes upstream that you haven’t pulled yet. If a collaborator pushed changes upstream after you had cloned, your push will not be successful. You will have to pull new changes and merge them with your branch before you can successfully push your changes upstream.

How can we stage a file?

NEED RESEARCH.

How can we unstage a file?

git reset HEAD index.html

To have a file return to its state when you last committed, utilize the git checkout command:

git checkout -- index.html

How can we undo a commit?

To undo changes resulting from a particular commit, use the git revert command. This command appends a new commit that undoes changes introduced by a specific commit. This prevents Git from losing history.

git commit -m "Example Commit"
git revert HEAD

NOTE: git checkout — file erases any changes made to the file because you are copying another file over it. Almost all committed information in Git can be recovered; however, any uncommitted information can be lost forever.

What is the meaning of the 'master' branch?

A collaborator can create a branch, work on it and save commit snapshots within it, switch between various branches, and merge changes. A Git branch is basically a movable pointer that always points to the most recent commit, or snapshot. Git uses the default local branch name “master,” which can be changed. Just because the default name is “master” does not imply that it is higher in importance or has more functionality than other branches. The head is a special pointer which indicates which branch you are currently working within.

How can we see the latest commit messages for each branch?

git branch -v

How can we see which branches are already merged into the branch we’re on?

$ git branch --merged
test
 * master

How can we see all the branches that contain work you haven’t yet merged in?

$ git branch --no-merged
testing

What is rebasing?

A popular alternative to merging is rebasing. Rebasing starts with the common ancestor of two branches: the one you’re on and the one you’re rebasing onto. Then, the diffs resulting from each commit of your current branch are saved to temporary files, and the current branch gets reset to the same commit as that of the branch you are rebasing onto. Last but not least, all changes get applied to the branch you are rebasing onto.

This process essentially rewrites a project’s history by replaying all changes committed on one branch to another one, leading to cleaner application of commits on a remote branch and a linear history.

git checkout test
git rebase master

What is Aliases?

Aliases allow users to navigate Git in an easier fashion. To save time and effort, one can create aliases for Git commands, which eliminates the need to type out an entire default Git command. You can set up aliases using the git config command.

$ git config --global alias.br branch
$ git config --global alias.st status
$ git config --global alias.co commit

The above commands allow the user to simply type git br, git st, or git co, instead of git branch, git status, or git commit. You can also create new commands with an alias.

git config --global alias.stage “add”

The above command makes git stage equivalent to git add. Many people create a last command for viewing the most recent commit:

git config –global alias.last “log -1 HEAD”

What is a typical workflow for Git?

If I want to contribute to a project / repository that I do not have write access to, I can fork (clone) the repository. In other words, I create my own repository. If I fork (clone) a repository on GitHub using the GitHub interface, the new repository is created on GitHub instead of my local computer. I can make make changes and commit my changes. However, my committed changes do not automatically show up in my own repository. I have to push my changes there using the git push command. If I want to have my changes show up in the main repository (the one that I cloned from), I have to send the owner of that repository an email, or somehow send him / her a pull request.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License