git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Shourya Shukla <shouryashukla.oo@gmail.com>
To: git@vger.kernel.org
Cc: sandals@crustytoothpaste.net, gitster@pobox.com,
	martin.agren@gmail.com, emilyshaffer@google.com,
	Shourya Shukla <shouryashukla.oo@gmail.com>
Subject: [PATCH v2 1/1] gitfaq: append the 'Common Issues' section
Date: Mon, 13 Apr 2020 16:25:29 +0530	[thread overview]
Message-ID: <20200413105529.16693-2-shouryashukla.oo@gmail.com> (raw)
In-Reply-To: <20200413105529.16693-1-shouryashukla.oo@gmail.com>

Add more issues and their respective solutions in the 'Common Issues'
section of gitfaq.

Signed-off-by: Shourya Shukla <shouryashukla.oo@gmail.com>
---
 Documentation/gitfaq.txt | 104 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt
index 1cf83df118..fc261cbbf5 100644
--- a/Documentation/gitfaq.txt
+++ b/Documentation/gitfaq.txt
@@ -223,6 +223,110 @@ 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.
 
+[[rebasing-and-merging]]
+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
+	commit.
++
+Now that we have an idea of the key differences between merging and rebasing, we can look at the
+circumstances when we would want to perform them. Generally, merging is preferred when one desires
+to create a new feature, perform its integration testing with the original codebase, and finally
+integrate it if all tests are passed. One would choose to create a separate branch for this purpose
+and maybe dissolve it when the merge is done.
++
+One might want to perform a rebase when they intend to retain the changes made in a separate branch
+into their original branch. In that case, a rebase would place the former changes onto the commit tree
+of the latter.
++
+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., all in one package.
+
+[[files-in-.gitignore-are-tracked]]
+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'. Consequently, `git add` does not list these files as 'modified' even if any
+	change was made in them and `git status` does not bother to track the changes in these files
+	either.
+
+	But, '.gitignore' will only ignore the files which were not a part of the repository when they
+	were mentioned in the it. 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 amend this mistake, i.e.,
+	to untrack and completely ignore a tracked file, 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(presuming
+	the file has been added in the 'gitignore'). This will hence make our file behave exactly like
+	we described in the paragraph above.
+
+[[changing-remote-of-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.
+
+[[fetching-and-pulling]]
+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
+	repository.
+
+	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.
+
+[[checking-out]]
+What is checking out a commit/branch? How do I perform one?::
+	In Git terminology, a 'checkout' serves three purposes, namely:
+
+		1. Go to another 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., referring to a named branch(say, master).
+		   Instead the aforementioned pointer is referring to the specified commit. I can now work upon the
+		   checked out commit and make any changes or just inspect the files at that state.
+
+		2. Go to a different version of a particular file; let's say I want to go to a particular version
+		   of a file in my working tree. I can again "checkout" to that particular version(i.e., going to a
+		   particular commit where certain changes were made). This can be done by entering the SHA1 of the
+		   commit in question. 
+
+		3. 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 w.r.t.
+the HEAD. To checkout to a particular version of a file, one can use `git checkout <SHA1/reference> <file>`.
+To checkout to an already existing branch, one should use `git checkout <branch-name>`. To simultaneously create
+and checkout to a branch, one can use the `-b` option in the aforementioned command.
++
+One can observe how versatile the checkout command is, yet due to simplify things even further, two commands were
+introduced in version 2.23 of Git so as to break down the functionalities of `git checkout` and make it learning
+the command easier for a beginner. The commands being `git switch` and `git restore`.
++
+`git restore` combines the first two features of the checkout as well as functionalities of `git reset` and `git revert`
+at one place so as to improve the functionality of the command.
++
+`git switch` perfoms the third functionality of the `git checkout` command, i.e., manipulating branches(creation).
+
 Hooks
 -----
 
-- 
2.20.1


  reply	other threads:[~2020-04-13 17:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 10:55 [PATCH v2 0/1] update gitfaq Shourya Shukla
2020-04-13 10:55 ` Shourya Shukla [this message]
2020-04-13 14:09 Shourya Shukla
2020-04-13 14:09 ` [PATCH v2 1/1] gitfaq: append the 'Common Issues' section Shourya Shukla
2020-04-14  1:06   ` brian m. carlson
2020-04-14  7:33   ` Junio C Hamano
2020-04-16 19:05   ` Junio C Hamano
2020-04-21  6:58     ` Shourya Shukla
2020-04-16 19:36   ` Junio C Hamano
2020-04-21  0:57   ` Junio C Hamano
2020-04-21  8:38     ` Shourya Shukla
2020-04-21 18:00       ` Junio C Hamano

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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 \
    --in-reply-to=20200413105529.16693-2-shouryashukla.oo@gmail.com \
    --to=shouryashukla.oo@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.agren@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    --subject='Re: [PATCH v2 1/1] gitfaq: append the '\''Common Issues'\'' section' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

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).