Skip to content

Using git

Jump to bottom Edit New page
H. Phil Duby edited this page Nov 1, 2018 · 1 revision

Working with local wcrs git repositories

Summary. Follow footnote (and other) links for additional details.

  • clone repository to work with 1 ¦ git clone «repository-url»
  • change to the repository folder 2 ¦ cd «path-to-repository»
  • pull remote updates to your local repository repository to work with 3 ¦ git pull
  • add and make changes to repository content4
  • add new and modified files to staging 5 ¦ git add [-A|«file-pattern»]
  • save staged changes to local repository 6 ¦ git commit [-m "one line commit message"]
  • update the github repository with the local changes 7 ¦ git push

Learn more about git

Setup

Many linux based operating systems come with git already installed. This document is not going to go through all of the possible ways of making the application available for use. See the git home page for information. This gist contains a summary that looks generally correct. The Red Hat details are a bit old. Use sudo dnf instead of sudo yum for recent distros (including Fedora). The full online book for git installation instructions in the Getting Started chapter.

Once the git application has been installed, it needs to be configured. The Getting Started chapter has a section for First-Time Setup. The main thing, when intending to work with github repositories, is to have the user.name and user.email configuration values set. That information will be stored in the commits, and is part of the change history.

Work Flow

Once a repository has been cloned to a folder on your local machine, the general work flow is as follows:

  1. Add new files, and modify existing files, in the local repository.
  2. Add new and changed files to staging.
  • Not all files need to be staged. Only those that are intended to be part of a single commit should be staged.
  • Repeat 1) and 2) until all files that belong to a single (logical) change have been staged.
  1. Commit the staged changes to the local repository.
  • Include a description of what changes were included in the commit. If a single line is not sufficient for a good description, make the first line a summary, leave the second line blank, and include additional description below that.
  • Repeat from 1) or 2) until ready to synchronize the changes with the remote repository
  1. synchronize the local and remote repositories (push)
  • Continue from 1) or 2) for the next set of changes
  • This can fail if there are conflicting changes already in the remote repository. Git tries to help resolve things, to merged the different changes, but sometimes it can not be done automatically. Ask for help, or learn more about resolving commit conflicts.

If other people are (or have been) working on the same remote repository (and same branch), usegit pullto synchronize their changes into the local repository. This should always work if there are no changes pending in the current repository. If there are pending changes, staged or not, the pull will fail, if the other changes touched any of the same files. More work will then be needed to get new changes into the remote repository.

git status can be used at any time, to get information about the state of the local repository. It will show things like the current branch, new and modified files that are not yet staged, file that have been stated but not committed. It also show when changes have been committed, but have not been pushed.

Footnotes:

  • (1) Cloning a git repository is done from the location the copy of (folder for) the repository is to be stored. git clone «repository-source» When the repository to be cloned is on github, repository-source is a URL pointing the repository on github. To get that, browse to the repository home page. You do not need to be logged in to do that. You can start from the WCRSyyc organization page, then follow the link to the desired repository. If using a fork of a wcrsyyc repository, start from your own github dashboard instead. The clone of a repository is a new repository. The clone is the local repository. The original is the remote repository Click the green Clone of download button on the code tab. If the popout does not show Clone with HTTPS, click Use HTTPS. Finally, click the folder icon at the right of the single line text box. That will copy the complete repository path into your clipboard. In your terminal window, type git clone , including a trailing space character, then paste the repository URL and press the enter (or return) key. Usually, right click (ctrl click on Mac) in the terminal window will show a context menu that can be used to paste↩

  • (2) In your terminal window, changed the current working directory to be the folder that the repository is stored in. cd «path-to-local-git-repository» ↩

  • (3) This updates the local git repository with any changes that have been made to the repository it was cloned from. This is not needed immediately after cloning. Its a good idea to do this before starting a new change, to synchronize with any changes that someone else may have pushed. It is always safe to attempt to do a pull. If there are any conflicts, the pull will just fail with an error message. In which case, more work will need to be done to get the content lined up again↩

  • (4) Use your favourite tools to create, modify, review content for the repository. That can be text editors, image manipulation programs, and more. Repository content is just files. The revision control functionality of git works best with text files (like markdown and source code). Binary files, like images and spreadsheets will also work, but the change history will be for the whole file, instead of just the lines that actually changed↩

  • (5) Staging files tells git what changes to include in the next commit. git add «single-file» git add «wild-card-pattern» git add -A Added and modified files can be stage individually, by file name patterns, or all at once. Only files that have been stage will be included in the next commit. Files that have been staged can still be modified before committing. To include any changes done after staging, just stage the file(s) again.↩

  • (6) Staged files are ready to be added to the local repository. To actually save the files to the repository, a commit is needed git commit git commit -m "one line description of changes being committed" The first form will open the configured text editor, to allow entering the change description for the commit. That allows multiple lines of text. The second form uses the quoted string as a single line description↩

  • (7) Changes are committed only to the local repository. To synchronize those changes with the remote repository, the committed changes need to be pushed. git push The push command will ask for authentication information for for the remote repository. That will be your github username and password↩

Add a custom footer
Add a custom sidebar
Clone this wiki locally