git checkout
One can either checkout a file or a commit d3dadaw in the commit history of the project. There are notable differences between these two processes.
When one checks out a file from a previous commit, the file replaces its counterpart in and is put in the staging area. This means that one can modify the file, git add and git commit to record any changes as part of the project history. To discard any changes, one must git reset and checkout a fresh version from master, or do a git reset --hard.
If changes made to the file that was checked out have been staged but not commited, then one must unstage them first using git reset, followed by a git checkout file to revert to the latest committed version of the file. If the changes have already been committed, one needs to reset to an older commit and checkout the version of the file from the latest commit, or the one that is desired.
N.B.: Perhaps this can be solved by branches and merging when I read about that.
P.S.: reset basically unstages and/or uncommits (local changes), which can be followed by a checkout in a straightforward way, or simply a hard reset.
There is a nice example on the Atlassian tutorial page.
The whole of the current directory is made to look like what it did at the time of said commit. Any changes made to files here cannot be part of the current branch's history. A new branch must be created to record the changes, and then a merge of some kind done to incorporate the changes into master. One can also stash any changes made checkout master to recover the project at the state of the latest commit.
N.B.: A nice feature here is that git will not let you check out a previous commit unless any changes since the latest commit have been staged and committed!
In git, you have access to a dedicated local version-controlled development environment. You can pull from/push to other non-local repositories using the git remote command
git remote -v: list all remote connections with url
git remote add
git remote rm
git remote rename
The git fetch commands allows you to look at changes from a(ll) branch(es) before incorporating them in one's local repo.
git fetch <remote>
git fetch <remote> <branch>
git pull remote does the same thing as a git fetch followed by a git merge. So it fetches changes to remote branches, without intengrating them right away into the local repo. It follows this by merging remote branches into local ones.
Rebasing is a way to ensure a linear commit/change history. It's basically saying "I'd like to put my changes on top of everybody else's". It's so common that a way to automatically build it into one's workflow is
git config --global branch.autosetuprebase always
git pull --rebase
git checkout master && git pull --rebase origin
There's a way of 'cleaning-up' one's changes first with a interactive rebase before pushing them. More about rebasing here!
Basically, you create a new branch from master, do your thing, maybe make changes to master along the way, you checkout the new branch, rebase it from master, checkout master and do a fast-forward merge.
The rebasing process pauses at times to resolve conflicts. To carry one after taking care of conflicts,
git rebase --continue
"If you get to this point and realize and you have no idea what’s going on, don’t panic. Just execute the following command and you’ll be right back to where you started before you ran git pull --rebase
git rebase --abort
git push <remote> <branch>
git push <remote> --all
git checkout master
git fetch origin master
git rebase -i origin/master
# Squash commits, fix up commit messages etc.
git push origin master
git push -u origin marys-feature
"This command pushes marys-feature to the central repository (origin), and the -u flag adds it as a remote tracking branch. After setting up the tracking branch, Mary can call git push without any parameters to push her feature."
git branch -r lets you see which branches you might see after fetching from a remote.
Note that one refers to remote branches as <remote>/<master>, so that all commands that accept a local branch can work with this syntax.
git branch <branch>
Create a new branch called .
git branch -d <branch>
Delete the specified branch.
git branch -D <branch>
Force delete the specified branch.
git branch -m <branch>
Rename current branch to branch
Unlike a checkout on a commit, a checkout on a branch is not a read-only operation. The directory is made to look like the branch and changes can be staged, committed etc...
git checkout <existing-branch>
"Check out the specified branch, which should have already been created with git branch. This makes the current branch, and updates the working directory to match.""
git checkout -b <new-branch>
"Create and check out . The -b option is a convenience flag that tells Git to run git branch before running git checkout ."
git checkout -b <new-branch> <existing-branch>
"Same as the above invocation, but base the new branch off of instead of the current branch."
# Start a new feature
git checkout -b new-feature master
# Edit some files
git add <file>
git commit -m "Start a feature"
# Edit some files
git add <file>
git commit -m "Finish a feature"
# Merge in the new-feature branch
git checkout master
git merge new-feature
git branch -d new-feature
git merge <branch>
You always merge branch into the current branch. One can either do a fast-forward merge, or a three-way merge. In the former case, there is a linear commit history from HEAD of current branch to HEAD of branch one is merging into. In the latter case, the branches have diverged, so that one must go back to the most common ancestor first.
To handle merge conflicts, running a git status lets you know which files need resolving.
Interesting, if you are on a branch, you can simply merge another remotely tracked branch using a git pull
git checkout master
git pull
git pull origin marys-feature
git push
The Centralized workflow is just like in svn or other legacy vcs. The Feature Branch Workflow leverages git's distributed collaboration framework (pull requests etc...). In both of these cases, there is one central server-side repo. In the Forking Workflow, there are multiple server-side repos.
Submodules allow you to link git repos with one another as 'folders'. When you fork someone's git repo, which has submodules, you must also fork the repos corresponding to the submodule. In your clone of the main repo, you must modify the .gitmodules file and clone your fork of the submodule. More info here!
- In the beginning
- There was nothing
- And then, there was something
- In the end
- There will be something
- And then, perhaps, nothing.
for i in range(10):
print i**2
"Do you have time to meet?" That's what she asked.
A block quote with two paragraphs.
| Foo | Yoyo |
| Hey hey hey... | Good byyyee!! |
Made this edit in tstrp1, and pushed. Then made edit in tstrp2 to see what happens (merge)!
Potential conflict here with two different versions of the file!
Conflict resolved!!