Thông tin Git cơ sở: An Intro for Beginners

Git is a version control system that's used extensively by the Drupal community.  It lets you and your team manage snapshots of your project.

Here are several benefits:

• Coordinate concurrent work
• Avoid teammates overriding your files.
• Organize your team's development cycle.
• Facilitate feature-based development methodologies.
• Restore all or parts of previous work done within a project.
• Minimize loss if your computer breaks, all but the latest work will have been stored remotely.

If you’re new to Git, you may be feeling a bit overwhelmed. However, once you get the hang of it, you won’t look back.

This attempts to build knowledge of Git from the ground up, assuming you know nothing about it.

 The rest of this post will introduce Git jargon with examples:

Git server (noun) - The keeper of all snapshots from one or more projects, usually hosted remotely on a linux box somewhere, perhaps github.com,

Repo (noun) - Short for “repository", this contains all snapshots of your project.

Branch (noun) - A branch is a collection of snapshots with a related purpose, perhaps a new feature for your website or a new phase of development. Typically, the version your team is actively working on is going to be called “develop”. Also typically, though not always, the latest, greatest, version that’s being used on a live website is called “master”.

Branch (verb) - To branch is to take a copy of a branch and save it as a different branch. You might create a new branch if you're about to get started on a new feature for your website and want to avoid conflicts with other teammates’ ongoing work.

Clone (verb) - Downloading a copy of all branches along with all their snapshots from the Git server. If someone tells you to "clone a repo", they’re just telling you to download a copy of the whole thing to your local machine.

In most cases, when you first clone a repo, the branch you start with will be the most stable branch, typically called “master”. As modifying this branch is usually reserved for a deployment workflow, your immediate next step should be to switch to the branch used for development, usually “develop”.

git clone [email protected]:example_company/example_project.git

The branch command can give you a list of available branches, with the “-a” option showing both local and remote branches:

git branch -a

Checkout (verb) - When you want to switch from your current branch to a different branch, you “checkout” the new branch.

Say your branch has ten files and the new branch has five. When you switch, you will now only see the new branch’s five files; however, if you “checkout” your previous branch then your former work will still be there.

git checkout develop

To create a new branch from an existing branch:

git checkout the_existing_branch
git checkout -b new_feature

The branch command can also delete branches:

git branch -d branch_to_delete

Status (noun) - Use status to see information about the current branch you’re using as well as any files you’ve added (staged):

git status

Origin (none) - This is a common name for the copy of the repo on the Git server.

Add (verb) - Before committing changes, add the files or directories that should be included with this commit. You can also see the files that have been added to the upcoming commit or modified but not added. Adding files to an upcoming commit is also referred to as “staging”.

git add test.txt
git add test2.txt
git add js/

Commit (verb) - This is the process of creating a new snapshot of the project within a given branch on your local machine:

git commit

Commit (noun) - This is what you might call one of the snapshots of the project within a given branch. Somebody might say, “The latest commit broke something.”

Push (verb) - This sends local changes you have committed up to the Git server. In other words, this syncs your local work with Git server’s copy of the repo for others to access.

git push origin develop

Fetch (verb) - When using Git, you’re dealing with your local copies of all branches versus what’s on the Git server everybody’s referencing. Fetching asks the Git server to send you the latest changes since you last fetched, or if you’ve never fetched, since you last cloned.

This means, you’ve got both your “develop” branch you’re working on along with a copy of the latest snapshot from the Git server, commonly named “origin/develop”. Please note that fetching alone does not update your local files. Merge does.

Merge (verb) - “merge” takes the changes that needs to be added/modified and puts them into the most recent (HEAD) snapshot of your branch.

git fetch
git merge origin/develop

Conflict (noun, expletive) - This is where things can get tricky.

When merging, conflicts can arise when you have modified a file that another team member has also modified and pushed up to the Git server before you had a chance to push your change. It may look something like this:

git merge origin/develop

The error:

Updating 07cd02f..f8c80c8
error: Your local changes to 'test.txt' would be overwritten by merge. Aborting.
Please, commit your changes or stash them before you can merge.

At this point, you’ll need to resolve the conflicts before the merge can be done.  First, you might want to see what’s changed by doing a diff:

git diff develop:test.txt origin/develop:test.txt

You might also want to see the log of Git commits:

git log

There are many ways to proceed, some better than others. To keep things simple, here are a couple tricks that will require you to reapply your work, but will not override your teammates’ work:

• Abandon changes in the conflicting file by using the latest snapshot from the Git server:
  git checkout origin/gryphon test2.txt
  git merge origin/gryphon
• Reject all conflicting local changes and just pull in the latest snapshot from the Git server, overwriting any conflicting files with those files’ versions on the Git server:
  git merge -s theirs origin/gryphon

Once conflicts are resolved you can apply changes.

Finally, it’s worth mentioning that these merging or conflict resolution approaches may not be appropriate for your project. When in doubt, research and then ask a team member.

Do not ask Git to do things you do not understand.

Git Gurus, what other tips might be useful, yet clear for Git beginners? Could anything here be re-stated more clearly or simply? Let’s discuss and refine this post in the comments below.

Additional resources:

• Webinar: Git Intro
• Git-Flow for Daily Use