Initialize Repo init
Check repo for unstaged/untracked files status
Stage/track filesadd
Commit repo- take snapshot of current statecommit
Display difference between current state and commitdiff
Display commit historylog
Move between commits and branches (also create branch w/ -b)checkout
Revert to past commitsreset
Create branchbranch (alsocheckout -b)
Merge local branchesmerge --no-ff [branch]
Handling merge conflicts
Create remote repo on Github Github UI
Clone remote repoclone URL
Initial (non-master) branch push to remotepush -u origin
Pull remote (upstream) branch to merge with localfetch``merge``pull
Make a pull request Github UI
Merge Flow
Rebase Flow ================================================================================================
$ git init initialize local repo
$ git status find current state of repo
$ git add [file(s)] Stage files for commit
-u add everything without listing files
$ git commit -m "message" takes snapshot of repo. Commits referenced by SHA (a unique id)
$ git diff display differences between unstaged changes and latest commit for all files
[path-to-file] for single file
--stat show high-level differences
Displays all commits with messages and SHA
$ git log
$ git checkout [SHA] resets HEAD to specfied SHA (HEAD is var that points to commit). In this way, 'travel' to different repo states.
$ git checkout HEAD~[number of commits to moveback] Alternate syntax. Don't have to log first, if you know how many commits you want to move back. $ git checkout master return to present repo state $ git checkout [branch] move to branch
Should only be done with code not being shared, i.e., local code that hasn't been pushed to remote repo. Use checkout to inspect previous commits, and reset to irreversibly revert back to.
$ git reset [SHA]
$ git reset HEAD~[number of commits to move back]
git reset --hard [SHA] or git reset --hard HEAD~[number of commits back]
Scenario: you're working locally, saving and running your app to test, and finally decide that you don't want to keep any of the changes you've made. git reset --hard
A branch is a parallel version of a repository. Example for when you'd want to make a branch is to develop a new feature. Changes made to branch have no effect on master, and vice versa. Once the feature is ready for production, the local branch is merged into master and then pushed out to production server.
git branch Display all branches. Asterisk (*) denotes active branch
git branch [branch-name] Create branch. Example: git branch feature/feature-name
git push -u origin [branch name] Create remote mirror of branch.
1. git branch -D features/featureA Delete a local branch and associated remote mirror
2. git push origin :features/featureA
git checkout [branch-name] Move to [branch-name]
git checkout -b [branch-name] Create and move to new branch in one step
Scenario and workflow: you are tasked with creating a new feature for a web app. First you would create a new branch, then switch to it with git checkout [new branch].
1.git branch [branch-name] Create branch
2.git checkout [branch-name]then move into it
git checkout -b [branch-name]Do both at once with checkout and -b flag
git push -u origin [branch name]
note: the -u flag establishes a tracking connection between local and remote branches so that succeeding pushes may be done with git push
It's time to merge your branch back into master after you've tested your feature and all is good to go. Before merging, it would be a good idea to run diff on the feature branch from master to verify that you're getting what you'd expect.
git checkout master
Note: Could run git branch here to verify in master branch and practice basic commands
git diff /features/feature-name
git merge features/feature-name
git log
Merge with --no-ff to retain info about the merge. Log will display Merge info line. Recommend using this always
merge --no-ff features/feature
git branch -d branch1
git push origin :branch1
Merge conflicts are a normal occurrence and happen when two branches have competing changes. Conflicts in files are wrapped by <<<<<<< HEAD [one branch's code] ========== [other branch's version] >>>>>>>
To resolve, simply edit code (You may want to keep code from different version, one or the other, or any variation thereof), remove <<<<<< HEAD ======== >>>>>>>, save file, and run git commit without -m
1. Click on new repo button after signing in to Github, name it, then click Create repository button
2a. Initialize local repo with git init in terminal, then copy and paste code from …or push an existing repository from the command line on Github into terminal and run it. The -u flag allows following pushes from local master to be done with truncated git push, rather than git push master.
2b. Could optionally first create remote repo on Github following steps above without first initializing local repo, then copy and paste code from …or create a new repository on the command line on Github into terminal and run it. It will accomplish the same thing.
Click clone button in repo on Guthub, copy URL, nav to local dir, and run git clone URL.No need to initialize local repo.
Suppose you have created a new branch locally to work on a feature and would like to push the branch up to Github. You cannot simply run git push in this instance, because only the master branch is being watched. You must explicitly tell git to create a new remote branch on Github with git push -u origin [branch-name].
This code should be familiar as it's essentially the same that was used to make the initial push of local master repo to Github
Scenario: Your collaborators have made changes to the master branch, and you would like to update your local repo to incorporate those changes into your code.
1. Navigate to local directory containing repo and make sure you're in master branch with git branch
2. Run git fetch. This pulls down all the remote changes to local repo, but does not merge them.
3. Compare files with git status. Will say that your branch is behind
4. Run git merge
May optionally run git pull which combines fetch and merge into one command
5. Resolve merge conflicts. This may require communicating with collaborators to grok their work.
A pull request is a formal request to merge a set of changes from one branch of a repo into another. Imagine you've added a new feature to a collaborative project, you've tried it out locally, and you're confident it works. After pushing to origin, you're ready to have that feature merged into the master branch of the project repository. It's time for a pull request, boy.
1. To initiate pull request, go to main repo page, and click on Pull requests tab, then New pull request button, which displays an interface to compare branches.
base -- this is the branch that you want to merge your work into
compare -- the branch that contains your work
In Thinkful lesson, the pull request involved master as base> branch and features/add-index-html as compare branch. In the mock scenario, we created a branch from master called feartures/add-inde-html created an index.html in it, and now we want to merge it with the remote origin master
2. Click Create pull request button, and fill out form, including name and description for the request. Both name and description should be concise and understandable at a high level.
3. Click Create pull request button. The page will update, and a new Merge pull request button will appear. At this point, you may add/review comments in files, by clicking on the Files changed tab to display them. Pull request is LIVE at this point.
4. Any changes requested are carried out locally and pushed from local to origin where they will show up in PR.
Rebasing 'prunes' the commit tree by splicing the base of the feature branch onto the latest commit of master. This results in a cleaner commit history that is easier to trace, but has the disadvantage of writing what is actually a false history.
In general, merge workflow should be used when working on public/open source projects, or other situations where history transparency is very important.
Both workflows involve the same creation of feature branches, but differ in how they incorporate the finished feature back into the master branch.
Scenario: you are in branch dev/feature and just finished testing to make sure everything is good to go.
Note: If the project is collaborative, you would first want to update local master with remote before merging/rebasing. This can be done by first moving to master git checkout master , then pulling master git pull master and resolving any conflicts if necessary.
-
After updating master, it's safe to merge.
git merge --no-ff dev/feature -
Delete dev branch
git branch -d dev/feature
-
After updating local master, move back into feature branch and rebase it onto local master, then resolve any conflicts
git rebase master -
Merge
git merge --no-ff dev/feature -
Delete dev branch
git branch -d dev/feature