As coding more and more,
git becomes a must-use tool to save the codes and control versions.
This is only a memo for myself to help with my daily work. If it’s also helpful to you, I’d be very happy.
Git is a local version control tool to help users, whether the user is a programmer of a writer, to manage the contents and changes in text files. If you would like to have a backup remotely, you could use Github to save your work on the remote repo.
If you use Ubuntu,
apt-get could be used to install git.
To create a new folder to hold the clone files, or you already have some work to track, you can use: :
After initialization, after some work, use
to add the specific file to the track; use
to add all changed files to the track.
If some specific type of files are not needed to track all the time, they can be added to the
.gitignore file. Just create a file named
.gitignore and then add the file types or names not necessary to track as the following. Then git will automatically ignore the files listed in the
Or you can use
commit into one sentence.
git commit -am only commit the files already in the track, and ignore the files which have never been added into the track.
The files then are all downloaded in the file.
git clone, and
git will create a new folder to hold the clone files for you.
--branch <branch> can specify the branch you want. if no branch is specified, the default branch would be
<directory name> can specify the place you want to put the repo. if no directory name is specified, the name of the repo would be used as the folder’s name.
After do some changes,
push to the remote repository.
The files in the Github is up-to-date.
Always pay attention to the branch you currently work on.
All the local branches would be shown, and one
* is in front of the name of current branch.
You can use
checkout to create or switch between the branches.
git checkout to the target branch
<branch name 1> and merge contents on
<branch name 2> into it.
List the current configured remote repository for your fork.123git remote -vorigin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
Specify a new remote upstream repository that will be synced with the fork.1git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git
Verify the new upstream repository you’ve specified for your fork.12345git remote -vorigin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)
Fetch the branches and their respective commits from the upstream repository. Commits to
masterwill be stored in a local branch,
upstream/master.1234567git fetch upstreamremote: Counting objects: 75, done.remote: Compressing objects: 100% (53/53), done.remote: Total 62 (delta 27), reused 44 (delta 9)Unpacking objects: 100% (62/62), done.From https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY* [new branch] master -> upstream/master
Check out your fork’s local
masterbranch.12git checkout masterSwitched to branch 'master'
Merge the changes from
upstream/masterinto your local
masterbranch. This brings your fork’s
masterbranch into sync with the upstream repository, without losing your local changes.12345678git merge upstream/masterUpdating a422352..5fdff0fFast-forwardREADME | 9 -------README.md | 7 ++++++2 files changed, 7 insertions(+), 9 deletions(-)delete mode 100644 READMEcreate mode 100644 README.md
If your local branch didn’t have any unique commits, Git will instead perform a “fast-forward”:12345git merge upstream/masterUpdating 34e91da..16c56adFast-forwardREADME.md | 5 +++--1 file changed, 3 insertions(+), 2 deletions(-)
Syncing your fork only updates your local copy of the repository. To update your fork on GitHub, you must push your changes.
Never reset/rebase actions which have been made in public branches.
Once you understand what rebasing is, the most important thing to learn is when not to do it.
The golden rule of
git rebaseis to never use it on public branches.
Below is the summary. Detail article can be found in Atlassian Git Tutorial.
|Command||Scope||Common use cases|
|git reset||Commit-level||Discard commits in a private branch or throw away uncommited changes|
|git reset||File-level||Unstage a file|
|git checkout||Commit-level||Switch between branches or inspect old snapshots|
|git checkout||File-level||Discard changes in the working directory|
|git revert||Commit-level||Undo commits in a public branch|
You can find detailed explanation here.
If you would prefer a clean, linear history free of unnecessary merge commits, you should reach for
git rebaseinstead of
git merge when integrating changes from another branch.
On the other hand, if you want to preserve the complete history of your project and avoid the risk of re-writing public commits, you can stick with
git merge. Either option is perfectly valid, but at least now you have the option of leveraging the benefits of