About - Git Branching and Merging The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model. Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds. This means that you can do things like: Frictionless Context Switching. Notably, when you push to a remote repository, you do not have to push all of your branches. There are ways to accomplish some of this with other systems, but the work involved is much more difficult and error-prone. Small and Fast Git is fast. Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Benchmarks Let's see how common operations stack up against Subversion, a common centralized version control system that is similar to CVS or Perforce. For testing, large AWS instances were set up in the same availability zone. Distributed
Version Control for Designers – This works on the assumption the person has no previous knowledge about SCM – What have you done for me lately? Version control, also known as source control or revision control is an integral part of any development workflow. Version control allows programmers to easily communicate their work to other programmersallows a team to share codemaintains separate “production” versions of code that are always deployableallows simultaneous development of different features on the same codebasekeeps track of all old versions of filesprevents work being overwritten What is version control? Version control, alternately known as revision control or source code management, is a system that maintains versions of files at progressive stages of development. There are many different programs for version control. Repository Structure The simplest version control system consists of a repository where all the files and their versions live. Figure 1: A basic source control system Branches Workflow Making changes
Made of Bugs » Versioning dotfiles in git I've been looking for a good solution for versioning and synchronizing my dotfiles between machines for some time. I experimented with keeping all of ~ in subversion for a while, but it never worked out well for me. I've finally settled on a solution that I like using git, and so this is a writeup of my workflows for working with my dotfiles in git, in the hopes that someone else might find it useful. You will not find any scripts here, only a description of a workflow: It's simple enough that I have not felt the need to script any of the pieces, even though I potentially could. On the machines On each machine, I have the dotfiles directory checked out into ~/.dotfiles/, and a symlink farm from the actual files in ~/ into ~/.dotfiles. Branches I maintain one branch for each machine or group of machines I keep dotfiles on. Synchronizing Periodically, I fetch that repository into another working copy, and synchronize the branches. Final thoughts
Community Mailing List Questions or comments for the Git community can be sent to the mailing list by using the email address git@vger.kernel.org. Bug reports for git should be sent to this mailing list. You do not need to subscribe: you will be Cc'd in replies. By subscribing (click here), you can make sure you're not missing follow-up discussions and you can also learn about other development in the community. Windows-specific questions can also be sent to the Git for Windows mailing list (if in doubt whether your question is Windows-specific, just use the general Git mailing list). There is also Git user mailing list on Google Groups which is a nice place for beginners to ask about anything. Bug Reporting Bugs in git can be reported directly to the mailing list (see above for details). Bugs related to this website can be reported at its issue tracker. If you are new to submitting bugs, you might find this guide helpful for producing useful bug reports. Reporting Security Issues IRC Channel
Ignore files From time to time, there are files you don't want Git to check in to GitHub. There are a few ways to tell Git which files to ignore. Create a local .gitignore If you create a file in your repository named .gitignore, Git uses it to determine which files and directories to ignore, before you make a commit. A .gitignore file should be committed into your repository, in order to share the ignore rules with any other users that clone the repository. GitHub maintains an official list of recommended .gitignore files for many popular operating systems, environments, and languages in the github/gitignore public repository. If you already have a file checked in, and you want to ignore it, Git will not ignore the file if you add a rule later. git rm --cached Create a global .gitignore You can also create a global .gitignore file, which is a list of rules for ignoring files in every Git repositories on your computer. git config --global core.excludesfile ~/.gitignore_global Explicit repository excludes
The Journey to Git, Part X—Communicating Between Repositories So you want to do some collaboration using Git. If you don't know where to start, you're in the right place. Start here. This post, like my earlier Git posts, will take you on a guided tour of how to collaborate with others (or yourself) using Git remoting. In this post, I assume you're comfortable working with a single Git repository with the basic commands like "git add", "git commit", "git branch", "git merge", and so on. Articles in this series: Making a Clone We need an existing repository to start from, so create a directory named "cloneme", change to it, and set up a repository like so: git init echo "foo" > foo git add foo git commit -m "first commit" Simple enough: a repository with one commit and one file being tracked. git clone clone Note: The "/path-to-cloneme" part should be the absolute path to the cloneme directory. You've just performed your first remote Git operation by cloning an existing repository. Getting New Changes from the Origin Repo git pull
Git Distributed version control software system Git ()[8] is a distributed version control system that tracks versions of files. It is often used to control source code by programmers collaboratively developing software. Git was created for use in the development of the Linux kernel by Linus Torvalds and others developing the kernel.[13] Git is a free and open-source software shared under the GPL-2.0-only license. The trademark "Git" is registered by the Software Freedom Conservancy, marking its official recognition and continued evolution in the open-source community. Today, Git is the de facto standard version control system. Torvalds wanted a distributed system that he could use like BitKeeper, but none of the available free systems met his needs. These criteria eliminated every version-control system in use at the time, so immediately after the 2.6.12-rc2 Linux kernel development release, Torvalds set out to write his own.[12] The read-me file of the source code elaborates further:[34]
Comment utiliser Git | University of Avignon and Open Source Software Comme promis, nous allons dans ce billet donner une rapide introduction à l’utilisation de Git pour les administrateurs système souhaitant gérer les mises à jour de leurs installations, ainsi que pour les contributeurs dans une seconde partie. Utilisation du dépôt pour maintenir facilement votre installation Première récupération des sources Vous voulez récupérer les sources de FileZ ou RdvZ avec Git et vous avez bien raison, voici donc quelques explications. FileZ et RdvZ sont des projets appartenant à l’utilisateur UAPV sur GitHub, vous pouvez donc les voir à cette adresse : git clone rdvz Vous voilà donc avec une copie du dépôt courant sur votre machine ! Choisir la version utilisée Hormis si vous souhaitez tester une nouvelle fonctionnalité, il est déconseillé de se placer sur la dernière modification envoyée par un développeur. git branch git tag Mettre à jour vos sources git fetch Contribuer Forker un dépôt Git workflow “Branchez”
GitSync – ezIX The problem ¶ Synchronising a directory tree between several computers. These computers may or may not be available online all the time and should allow local modifications without hassle (the usual check-out/commit cycle is too cumbersome for most users). The tools ¶ git, available on most (if not all) Linux distributions or any scheduling tool (cf. below for Mac OS X peculiarities) Creating the document archive ¶ With git, the working copy contains the archive itself (in the .git directory at the root of the working copy). To create the archive (if your documents are located under docs in your home directory): $ cd ~/docs $ git init $ git add . $ git commit -m "initial import" $ git clone --bare . that's it! Now we will create a "central" repository (we'll call that machine mainmachine) that will act as the master copy, with all other machines synchronising to it. Therefore, you shouldn't use ~/docs anymore but create a clone instead: You can get rid of ~/docs: #! <?
Git Multiple SSH keys for different github accounts create different public key create different ssh key according the article Mac Set-Up Git $ ssh-keygen -t rsa -C "your_email@youremail.com" Please refer to github ssh issues for common problems. for example, 2 keys created at: ~/.ssh/id_rsa_activehacker ~/.ssh/id_rsa_jexchan then, add these two keys as following $ ssh-add ~/.ssh/id_rsa_activehacker $ ssh-add ~/.ssh/id_rsa_jexchan you can delete all cached keys before $ ssh-add -D finally, you can check your saved keys $ ssh-add -l Modify the ssh config $ cd ~/.ssh/ $ touch config $ subl -a config Then added #activehacker account Host github.com-activehacker HostName github.com User git IdentityFile ~/.ssh/id_rsa_activehacker #jexchan account Host github.com-jexchan HostName github.com User git IdentityFile ~/.ssh/id_rsa_jexchan Clone you repo and modify your Git config clone your repo git clone git@github.com:activehacker/gfs.git gfs_jexchan cd gfs_jexchan and modify git config then use normal flow to push your code Another related article in Chinese
Preface Git is a version control Swiss army knife. A reliable versatile multipurpose revision control tool whose extraordinary flexibility makes it tricky to learn, let alone master. As Arthur C. Clarke observed, any sufficiently advanced technology is indistinguishable from magic. Rather than go into details, we provide rough instructions for particular effects. I’m humbled that so many people have worked on translations of these pages. Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. François Marier maintains the Debian package originally created by Daniel Baumann. John Hinnegan bought the gitmagic.com domain. My gratitude goes to many others for your support and praise. If I’ve left you out by mistake, please tell me or just send me a patch! This guide is released under the GNU General Public License version 3. or from one of the mirrors:
Set up git At the heart of GitHub is an open source version control system (VCS) called Git. Git is responsible for everything GitHub-related that happens locally on your computer. To use Git on the command line, you'll need to download, install, and configure Git on your computer. If you want to work with Git locally, but don't want to use the command line, you can instead download and install the GitHub Desktop client. If you don't need to work with files locally, GitHub lets you complete many Git-related actions directly in the browser, including: Setting up Git Next steps: Authenticating with GitHub from Git When you connect to a GitHub repository from Git, you'll need to authenticate with GitHub using either HTTPS or SSH. Connecting over HTTPS (recommended) If you clone with HTTPS, you can cache your GitHub password in Git using a credential helper. Connecting over SSH If you clone with SSH, you must generate SSH keys on each computer you use to push or pull from GitHub. Celebrate