From: Shourya Shukla <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
Shourya Shukla <firstname.lastname@example.org>
Subject: [PATCH 2/2] gitfaq: append the 'Common Issues' section
Date: Mon, 6 Apr 2020 23:42:16 +0530 [thread overview]
Message-ID: <email@example.com> (raw)
Add more issues and their respective solutions in the 'Common Issues'
section of gitfaq.
Signed-off-by: Shourya Shukla <firstname.lastname@example.org>
Documentation/gitfaq.txt | 72 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt
index 3ca16b1092..ccc14774ba 100644
@@ -223,6 +223,78 @@ a file checked into the repository which is a template or set of defaults which
can then be copied alongside and modified as appropriate. This second, modified
file is usually ignored to prevent accidentally committing it.
+How do I know when to merge or rebase?::
+ Rebasing and merging two entirely different concepts with different utiilites.
+ In Git terms, rebasing means to place changes made in one branch over another branch
+ (called base, hence the term rebase). The commit history of the branch wanting to rebase
+ get placed over the branch on the receiving end and it appears as if those changes took
+ place in the receiving branch itself. Merging, as the name suggests, merges the latest
+ commit of one branch onto the recent branch, making this combination appear as one separate
+As an additional tip, one can use interactive rebasing, `git rebase -i`, to perform rebasing
+using a text editor GUI (the value of $GIT_EDITOR). Interactive rebase is an excellent utility
+to perform various functions such as editing commit messages, dropping/squashing commits, editing
+commits, etc. in one package.
+I asked Git to ignore various files, yet they show up as changes in my staging area::
+ One uses `.gitignore` to ignore files from getting tracked in the working tree. This ignores
+ the aforementioned files for the whole lifetime of the project unless they area removed from
+ the `.gitignore`. But, `.gitignore` will only ignore the files which were not a part of the
+ repository when they were mentioned in the `.gitignore`. Hence, addition of a file to `.gitignore`
+ after it was added to the working tree will have no effect and Git will keep tracking them.
+ To prevent this from happening, one has to use `git rm --cached <file>` to remove the file
+ from the staging area(i.e. the cache) and not from the repository.
+I want to change the remote of my repository. How do I do that?::
+ A remote is an identifier for a location to which Git pushes your changes as well as fetches
+ any new changes(if any). There might be different circumstances in which one might need to change
+ the remote:
+ 1. One might want to update the url of their remote; in that case, the command to use is,
+ `git remote set-url <name> <newurl>`.
+ 2. One might want to have two different remotes for fetching and pushing; this generally
+ happens in case of triangular workflows. In this case, it is advisable to create a
+ separate remote just for fetching/pushing. But, another way can be to change the push
+ url using the `--push` option in the `git set-url` command.
+How do I know if I want to do a fetch or a pull?::
+ A fetch brings in the latest changes made upstream(i.e. the remote repository we are working on).
+ This allows us to inspect the changes made upstream and integrate all those changes(iff we want to)
+ or only cherry pick certain changes. Fetching does not have any immediate effects on the local
+ A pull is a wrapper for a fetch and merge. This means that doing a `git pull` will not only fetch the
+ changes made upstream but integrate them as well with our local repository. The merge may go smoothly
+ or have merge conflicts depending on the case. A pull does not allow you to review any changes made
+ upstream but rather merge those changes on their own.
+This is the reason why it is sometimes advised to fetch the changes first and then merge them accordingly
+because not every change might be of utility to the user.
+What is checking out a commit/branch? How do I perform one?::
+ In Git terminology, checking out means updating the current working tree with a another commit or
+ even a separate tree(which would translate to a branch). This means that if I were to:
+ 1. Go to another commit, to lets say modify stuff in that commit; I would be "checking out"
+ to that commit and enter a "detached HEAD" state, meaning, that the "pointer" called HEAD
+ which tells me where I am right now in my working tree is not where it generally should be,
+ i.e., the latest commit(or the tip of the branch). I can now work upon the checked out
+ commit and make any changes or just inspect the files at that state.
+ 2. Go to another branch or create another branch; I would be "checking out" to another tree
+ in my local repository. One might expect to enter a detached HEAD here as well but in fact
+ does not. This is because HEAD would point to the tip of the checked out branch, something
+ which is not a characteristic of a detached HEAD.
+To checkout to a commit, one can either pass the SHA1 of the commit to be checked out or a reference to it wrt
+the HEAD. To checkout to another already existing branch, one should use `git checkout <branch-name>`.
+Also, one can create a new branch as well as checkout to it at the same time using `git checkout -b <new-branch-name>`.
next prev parent reply other threads:[~2020-04-06 18:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 18:12 [PATCH 0/2] Add more issues in gitfaq Shourya Shukla
2020-04-06 18:12 ` [PATCH 1/2] gitfaq: cleanup gitfaq.txt Shourya Shukla
2020-04-06 19:06 ` Junio C Hamano
2020-04-06 23:46 ` Junio C Hamano
2020-04-07 1:07 ` brian m. carlson
2020-04-07 3:15 ` Junio C Hamano
2020-04-08 18:22 ` Pratyush Yadav
2020-04-10 18:29 ` Junio C Hamano
2020-04-06 18:12 ` Shourya Shukla [this message]
2020-04-06 19:28 ` [PATCH 2/2] gitfaq: append the 'Common Issues' section Junio C Hamano
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).