Cloning from a Remote
Ex. git clone https://github.com/myOwnFile/my_git_project.git
If you clone a repository, the source from which you cloned it from is designated as the origin remote by default. You may modify the remote using the git re- mote command.
It’s not necessary to keep the directory name; you can change it any time.
git clone https://github.com/myOwnFile/my_git_project.git my_project
You may also rename the directory after you’ve cloned the repository.
Once you’ve cloned the repository, you can verify that the origin remote points to the URL that you just cloned from, shown in Figure 4.2:
git remote -v
The available protocols for any Git remote are as follows:
-
Local protocol
git clone /Users/donny/my_git_project
is limited to the local computer.
Git protocol
If you clone over the Git protocol, your URL starts with git instead of https: git://github.com/sdaityari/my_git_project.git. This doesn’t provide any se- curity. You only get read-only access over the git protocol, and therefore you can’t push changes.
HTTP/HTTPS protocol
With the https protocol, your connection is encrypted. GitHub allows you to clone or pull code anonymously over https if the repository is public. However, for pushing any code, your username and password are verified first.
SSH protocol
GitHub recom- mends using https over ssh, because the https option always works, even if you’re behind a firewall or a proxy.
if you push your code frequently, you can make Git re- member your credentials for a given amount of time after you successfully enter them once. This is done with the credential.helper setting. Run the following to enable credential storage:
git config --global credential.helper cache
By default, Git stores your credentials for 15 minutes. You may also set the timeout limit in seconds:
git config --global credential.helper "cache --timeout=3600"
This command makes Git store your credentials for an hour.
To set up authentication using ssh, you need to generate your public/private key pair.
In Linux or OS X, the following command generates a key pair:
ssh-keygen -t rsa -C "This email address is being protected from spambots. You need JavaScript enabled to view it."
In Windows, you need either PuTTY or Git Bash to generate the key. GitHub provides detailed instructions on the process of generating the key pair on Windows
Your public key is stored in the file ~/.ssh/id_rsa.pub. You can view it using the cat command,
cat ~/.ssh/id_rsa.pub
This command pushes the code on the branch_name branch (irrespective of your current branch) to the remote branch of the same name. If branch_name doesn’t exist on the remote, it is created.
git push remote_name branch_name
This command pushes the local_branch from the local repository to the re- mote_branch of the remote repository :
git push remote_name local_branch:remote_branch
Delete Branches Using git push
You can modify the syntax listed above to delete a branch on the remote:
git push remote_name :remote_branch
In this command, you are essentially sending an empty branch to the re- mote_branch branch of remote_name, which empties the remote_branch, or in other words, deletes it on the remote.
To download the changes that have appeared in the remote, we run the following command:
git fetch remote_name
Following a fetch, to update your local branch you need to merge it with the appro- priate branch from the remote. For instance, if you’re planning to update the local master branch with the remote’s master branch, run the following command:
git merge origin/master
This is basically merging the branch origin/master with your current active branch.
Alternatively, a shorter way of updating the local branch by downloading and merging a remote branch is by using pull. The git pull command is essentially a git fetch followed by a git merge. To update the current active branch through pull, run the following:
git pull origin master
After initiating a merge that’s resulted in conflicts, if you’re overwhelmed and want to go back to the pre-merge state, you can do so by aborting the merge:
git merge --abort
Essentially, you should avoid committing directly to your master branch, but only keep it updated with the central repository. You work on your feature branch, and push the feature branch to the central repository once you complete your work. If your feature is accepted to the master branch of the central repository, this will be reflected in your local master once you pull changes from origin/master.
When you fork a project, you’re creating your own copy of the repository on the cloud.
A fork is a personal copy of a repository on a code sharing website like GitHub, BitBucket or GitLab. You have full write access to your fork, although you may not have write access to the main repository which was the source of the fork.
Once you’ve created a fork and cloned it to your local machine, you can experiment with it as you please. You can create branches, push them to your fork, and submit pull requests to the organization that maintains the original repository. If the organ- ization chooses to merge your changes, those changes will become a part of the central repository.
Undo Git Add : git rm --cached mistake_file
When we postfix --cached, we ask Git to untrack the file, but let it remain in the file system.
git rm is -f for forced removal. The -f option untracks the file and then removes it from your local system altogether.
Undo Git Commit : git reset --soft HEAD~1
The --soft option undoes a commit, but lets the changes you made in that commit remain staged for you to review. The HEAD~1 means that you want to go back one commit from where your current HEAD points (which is the last commit).
The second option here is postfixing the --hard option to permanently undo commits.
A third option of reset is --mixed, which is also the default option. In this option, the commit is reverted, and the changes are unstaged.
The --soft option takes us back to just before the commit, when the changes are staged. The --mixed option takes us back to just before the staging of the files, where the files have just been changed. The --hard option takes us to a state even before you changed the files.
The reset command changes the history of the project, but revert undoes the changes made by the faulty commit by creating a new commit that reverses the changes.
Here’s how to go back one commit using revert: git revert HEAD~1
You can change the commit message of the last commit by running the following command:
git commit --amend -m "New Message"
Undo Git Push
git revert HEAD~1
git push origin master
However, if you also want the other commit(s) to vanish from the remote repository, you first need to go for a reset command—deleting the unwanted commit—and then push the changes to the remote.
git reset --hard HEAD~2
git push -f origin master
Git Blame
Running the git blame command on a file gives you detailed information about each line in the file. git blame lists the commits that introduced changes in a file, along with basic information about the commit, like the commit hash, author and date.
git blame my_file
Git Bisect
git bisect start
git bisect good 7d1b1ec580
git bisect bad 083e7eef5cd
To combine the last three commands (start, good, and bad) into one, you may in- stead start the wizard with the following command:
git bisect start 083e7eef5cd 7d1b1ec580
Once you’ve found your faulty commit, you can exit the wizard by running the following:
git bisect reset
