Understanding the Workflow of Version Control presented by TOWER › Version control with Git - made easy
The Basics 1
Work on an Existing Project Start a New Project $ git clone
2 File Status Files that aren’t yet under version Work on Your Files control are called “untracked”… Modify, rename and delete files or add new ? …while files that your version ones. Do all of this in your favorite editor / control system already knows IDE / file browser – there‘s nothing to watch about are “tracked” files. out for in this step! A tracked file can either be “unmodified” (meaning it wasn’t changed since the last commit)...... or “modified” (meaning it has m local changes since it was last committed).
3
$ git status Keep the Overview # # Changes not staged for commit: $ git status # modified: about.html # deleted: robots.txt The “git status” command tells you what # happened since the last commit: which files # Untracked files: did you change? Did you create any new ones # login.html or delete old ones? # no changes added to commit
4
Add Files to the “Staging Area” $ git add about.html # $ git add
5
Commit all Staged Changes
$ git commit -m "message" $ git commit -m "Updated about page" A commit wraps up all the changes you previously staged with the “git add” [master 9d3f32b] Updated about page command. To record this set of changes in 1 file changed, 29 insertions(+) Git’s database, you execute the “git commit” command with a short and informative message.
6
Keep the Overview $ git status $ git status # Running the “git status” command right after # Changes not staged for commit: # deleted: robots.txt a commit proves to you: only the changes # that you added to the Staging Area were # Untracked files: committed. # login.html All other changes have been left as local # changes: you can continue to work with them no changes added to commit and commit or discard them later.
7
Inspect the Commit History $ git log $ git log commit 9d3f32ba002110ee0022fe6d2c5308 The “git log” command lists all the commits Author: Tobias Günther Branching & Merging 1 Understanding Branches BUGFIX #32 C4 FEATURE A C1 C3 C5 C7 FEATURE B C2 C6 Start a New Feature We often have to work on multiple things in parallel: feature X, bugfix #32, feature Y… $ git branch 2 HEAD Branch C6 C7 feature-b Switch Contexts C1 C4 C5 master $ git checkout To start working on a different context, you At each point in time, you can only work in need to tell Git that you want to switch to it. one context – the context of the currently You do this by “checking out” the branch with checked out branch (which is also called the the “git checkout” command. “HEAD” branch in Git). Every commit you make – until you switch Your project’s working directory contains the branches again – will be recorded in this files that correspond to this branch. When branch and kept separate from your other you check out a different branch (make contexts. it “HEAD”), Git replaces the files in your working directory with the ones that match this branch. 3 Integrate Changes $ git merge Sharing Work via Remote Repositories 1 Track a Remote Branch Publish a Local Branch $ git checkout --track Local & Remote Repositories 2 MODIFY, ADD & DELETE FILES MAKE COMMITS LOCAL SHARE WORK REMOTE Stay Up-To-Date COMPUTER SERVER LOCAL REMOTE About Remote Changes REPOSITORY REPOSITORY COLLABORATE VIEW HISTORY $ git fetch Integrate Remote Changes $ git pull To integrate new changes from the remote repository, you simply call “git pull”. This will update your current HEAD branch with new data from its counterpart branch on the remote. The changes will be directly merged into your local working copy. 4 Upload Local Changes to the Remote Server $ git push To upload the local changes you made in your Version control with Git - made easy current HEAD branch, all you have to do is 30-day free trial available at call “git push”. www.git-tower.com