Tutorial git
Original source: http://hoth.entp.com/output/git_for_designers.html
Version control, alternately known as source control or source code management is a system that maintains versions of files in the progressive stages of development. The version control system is similar in theory to back up your files, but smarter. Each file in the system has a complete history of changes, and can be easily restored to any version of history. Each version has a unique identifier that looks like a string of letters and numbers. (443e63e6..).
There are many different software version control. This document is based on git, but also can study Subversion (SVN), CVS, darcs, Mercurial and others. Each has a Slightly Different metaphor for operation.
http://hoth.entp.com/output/scm.png
Figure 1: A basic version control
While the simplest way is to have a canonical source for the repository, this is not necessary. Each user has a complete copy of the repository on your local machine. Generally, you apply changes to your local repository, and once it is complete, press down (push) your work to the shared repository on your computer. You can also pull (pull) of changes in other repositories
http://hoth.entp.com/output/dscm.png
Figure 2: A system of distributed source control
-8.7 +8.6 Source code revision control or management, is a system That Maintains versions This That I added a line to the file This is a line I removed from the file and . You can also tubing (pipe) the diff to a file.
This output is called a diff or match and may be sent by email to other developers so that they can apply your changes to your local codes. It is also human-readable: shows the file names, line numbers within the file, and changes with the symbols
ninja-owl: public Courtenay $ git diff – cached> line_modify.patch
Commit (commit) something in your life
When you have your changes so you want to add them to the current revision, then you need to commit (commit) this review to your local repository. To do this, you will need to run git commit. When you execute this command, you receive a text editor with a list of files that have changed and some empty space at the top. In this space, you need to describe what has changed so that your colleagues can tell at a glance what you have done. Need to enter something better than “thing”, but there is no need to write a will, and instead do something like:
434 in line Changed index.html to use Rather Than spaces tabs.
Changed line 800 in products.html.erb to Have Space Between the two tags.
Changed line 343, 133, 203, 59, and 121 to Have two spaces at the start Rather Than 9.
Corrta A description of what you have changed will be sufficient. The commit messages are an art form, like haiku.
Minor formatting changes file in the code.
It is acceptable to write a summary line (less than 80 characters), a blank line, then a third line describing in more detail. The second and third lines are optional.
Once you’ve written the commit message, save the file and quit the text editor. This will commit to your local repository, and you can continue with your work.
Push back
Once your changes have been “committed” to your local repository, you need to push (push) the remote. To do this, you will need to run git push, which will push all changes from your local repository to the remote.
The push to git takes several arguments:
git push <repository> <branch> </ Pre> In this case, we want to push changes back to the original repository, which is "nicknamed" as origin, to the branch master. <pre> $ Git push origin master </ Pre> Fortunately for our fingers, push git (and git pull) default push and pull of all the branches common to the origin and local repository. As you do push, you should see output similar to the following: <pre> your-computer: git_project yourusername $ git push updating 'refs / heads / master' from fdbdfe28397738d0d42eaca59c6866a87a0336e2 to 1c9ec11f757c099680336875b825f817a992333e Also local refs / remotes / origin / master Generating pack ... Done counting two objects. Deltifying two objects ... 100% (2 / 2) done Writing two objects ... 100% (2 / 2) done Total 2 (delta 3), reused 0 (delta 0) refs / heads / master: fdbdfe28397738d0d42eaca59c6866a87a0336e2 -> 1c9ec11f757c099680336875b825f817a992333e </ Pre> All this output basically says that you have your files ready to be pushed (pushed) (Generating pack) and the remote repository has received your files (Writing two objects). Then the remote repository has updated its head / master (the branch "main" repository) to the revision tipped you have committed (commit) by what is known as the last set of changes committed. Now others can update their local copies to be synchronized with the changes you've done. But how are you doing this? Get updates from afar To update your local repository and a working copy to the last revision committed to the remote repository, you need to run git pull. This "pulls" all changes from the remote repository and combines them with your current changes (if any). When you run a git pull, the output should look something like this: <pre> remote: Generating pack ... remote: Done counting 12 objects. remote: Result has eight objects. remote: Deltifying 8 objects ... remote: 100% (8 / 8) done Unpacking 8 objects ... remote: Total 8 (delta 4), reused 0 (delta 0) 100% (8 / 8) done * Refs / remotes / origin / master: fast forward to branch 'master' of git@yourco.com: git_project old .. new: 0c793fd fdbdfe2 .. Auto-merged file.cpp Merge made by recursive. . Gitignore | 2 + + file.cpp | 8 ++++++-- src / things.html | 5 +++-- your_file.txt | 18 ++++++++++++++++++ 4 files changed, 19 insertions (+), 4 deletions (-) 100 644 create mode. gitignore 100 644 create mode your_file.txt </ Pre> What has happened is basically a push in reverse. The remote repository has been prepared and transferred to your local repository changes (Unpacking 8 objects). Your local repository and then making the changes implemented in the same order they were committed (eg combined as the example for file.cpp or creating them as. Gitignore your tu_archivo.txt Note: The. Gitignore allows you to tell Git to ignore certain files and directories. This option is useful pathings like binary ra generated log files, or also those with local passwords on them. Branching You should always create a branch before starting work on a new feature. Thus, the master will always be in a stable state, and you'll have the opportunity to work in isolation from other changes. Creating new branches allows you to take the branch master, "clone", and apply changes to this "cloned." So when you're ready, you can mix your branch with the master, or, if there have been changes to the master while you were working, mix your own branch. It's like pulling and pushing, but everything happens in the same directory. The figure below illustrates the process. http://hoth.entp.com/output/branching.png Figure 3: Branching and mixing (merging) The branching is great for two people to work together on things that require isolation of the main codebase. This could include anything from code that will have permanent results, such as a really big code refactoring or redesign a site, to temporal things, such as performance testing. Creating a branch (Branch) To create a Branch in Git, you execute you git checkout - b name> rama>. Any modified file will be listed. <pre> $ Git checkout-b redesign M public / index.html Switched to a new branch "redesign" </ Pre> Now you've checked the branch redesign. To switch to the master, <pre> $ Git checkout master M public / index.html Switched to a new branch "master" </ Pre> You'll find very useful to establish the branch in the remote repository, so that others can pull your changes. <pre> $ Git push origin redesign </ Pre> You can also push your branch to another branch remotely different <pre> $ Git push origin redesign: master </ Pre> This sets the current working copy to commit and push all changes to branch redesign in local and remote repositories. Now any changes you add and comets live in this branch instead of the master. Aside: In what branch I am? To view your current branch, and to list all local branches git branch runs If you need to pull changes from your master branch (ie, major changes in code, security updates, etc) you can do using <pre> git pull: git pull origin git merge master </ Pre> This command tells Git to pull all changes from the repository origin (the name for the repository canonical Git remote) including all branches. Then combine the master branch to yours. When you're ready to combine with the master, you need to check to master, and then combine the branches: <pre> git checkout master git merge redesign </ Pre> Now your changes will be combined to the master branch from the branch redesign. If finished with the branch you created, you can delete it using the-d. git branch-d redesign To delete the branch in the remote repository, you must capture the push command (remember that you can push a local branch to a remote branch with git push <remote> <local branch>: <remote branch>) and send a local branch empties remote branch. git push origin: redesign More useful tools Undoing your changes You can remove a file from the staging with git reset HEAD <filename>. If you want to revert a file to copy in the repository, only Check it again. git checkout <filename> To revert a file to an older version, use git checkout. Need to know the ID of review, where you can find with git log <pre> $ Git log index.html 86429cd28708e22b643593b7081229017b7f0f8d commit Author: joe <joe@example.com> Date: Sun February 17 2008 22:19:21 -0800 build new html files 3607253d20c7a295965f798109f9d4af0fbeedd8 commit Author: fred <fred@example.com> Date: Sun February 17 2008 21:32:00 -0500 </ Pre> Oops. To revert the file to the older version (360 725 ...) run checkout. Git draw up the previous version for you, ready for review and commit. $ Git checkout 3607253d20c7a295965f798109f9d4af0fbeedd8 index.html If you do not want to restore this old version, you can go back again. <pre> $ Git reset HEAD index.html $ Git checkout index.html Or in a command $ Git checkout HEAD index.html </ Pre> Have you noticed that is interchangeable with the HEAD revision number? This is so because git, revisions and branches are effectively the same thing. Who wrote that line? Run git blame <file> to see who last changed the file and when. View the full tree You can view a detailed history of your working copy with gitk. http://hoth.entp.com/output/gitk.png Figure 4: Sample gitk screenshot Gitk application allows you to navigate through the tree of changes, see diffs, find old reviews and more. Best practices We think we can pass this section with a few hints and tips that can help when working with version control systems. Commits (commit) often Like when people always say "records often or you'll regret" when trabajs with word processors, you should commit to your local repository as often as possible. Not only protects you from the possibility of losing your job (should not happen if you follow the prime piece of this notice), but will give you security that you can go back anytime you need it. Of course, of course, commit Committing Every after-commit or commit wocommitrd lcommitecommittcommittcommitecommitrcommit could be a bit excessive. At each step you make to your work, you should commit. you take in your work, you should commit. Throw often Conversely, you should throw often. Shooting often keeps your code up to date and, hopefully, eliminate the possibility of duplicating work. It is always frustrating when you spend hours working on a property and your colleague and implemented and pushed to the repository, but did not know because it strips every three weeks. Use checkout and carefully reset To reverse any local changes you've made to a specific file from your last commit, you can use git checkout <filename>, or also use git reset to kill all changes since your last commit. Having the ability to back steps back is a great tool (especially if you realize that you follow a path completely wrong), but it's definitely a double-edged sword. Once the changes were, they were, so beware!. It's terrible when you realize you threw overboard a few hours of work for a reset of no return. Create your own repository anywhere. If you have some control simpre versions in a local project (eg, has a great remote repository or similar), then you can simply use git init to create your own local repository. For example, if you're working on some design concepts of an application, then you could do something like this: mkdir design_concepts git init Now you can add files, commit, branch, and so, as in a remote Git repository "real." If you want to push and pull, you need to configure a remote repository. I advise you to write setings in the "essay" http://custom-essay-writing-service.org/index.php and "safety Cover" http://www.cheappoolproducts.com. <pre> git remote add <alias> <url> <alias> master git pull </ Pre>
