#delete git branch local

[shieldfoss]

Git checkout autocomplete

when i do git branch (tab) I get a list of two options - the main branch and the one I created on this machine.

when I do git switch (tab) I get my two locals, but also a couple of extra options that are on the remote.

So Far So GoodExpected.

But when I do git checkout (tab) I get a bunch of stuff I don' t recognize: "DIsplay all 265 possibilities? (y or n)"

what... are these extra branches? My best guess is "old branches that were merged, but that merge remains part of git history despite the branch being deleted" - does that sound right?

[hindintech]

You can learn Git easily, Here's all you need to get started:

1.Core:

• git init

• git clone

• git add

• git commit

• git status

• git diff

• git checkout

• git reset

• git log

• git show

• git tag

• git push

• git pull

2.Branching:

• git branch

• git checkout -b

• git merge

• git rebase

• git branch --set-upstream-to

• git branch --unset-upstream

• git cherry-pick

3.Merging:

• git merge

• git rebase

4.Stashing:

• git stash

• git stash pop

• git stash list

• git stash apply

• git stash drop

5.Remotes:

• git remote

• git remote

• add git

• remote remove

• git fetch

• git pull

• git push

• git clone --mirror

6.Configuration:

• git config

• git global config

• git reset config

7. Plumbing:

• git cat-file

• git checkout-index

• git commit-tree

• git diff-tree

• git for-each-ref

• git hash-object

• git Is-files

• git Is-remote

• git merge-tree

• git read-tree

• git rev-parse

• git show-branch

• git show-ref

• git symbolic-ref

• git tag --list

• git update-ref

8.Porcelain:

• git blame

• git bisect

• git checkout

• git commit

• git diff

• git fetch

• git grep

• git log

• git merge

• git push

• git rebase

• git reset

• git show

• git tag

9.Alias:

• git config --global alias.<alias> <command>

10.Hook:

• git config --local core.hooksPath <path>

11.Experimental: (May not be fully Supported)

• git annex

• git am

• git cherry-pick --upstream

• git describe

• git format-patch

• git fsck

• git gc

• git help

• git log --merges

• git log --oneline

• git log --pretty=

• git log --short-commit

• git log --stat

• git log --topo-order

• git merge-ours

• git merge-recursive

• git merge-subtree

• git mergetool

• git mktag

• git mv

• git patch-id

• git p4

• git prune

• git pull --rebase

• git push --mirror

• git push --tags

• git reflog

• git replace

• git reset --hard

• git reset --mixed

• git revert

• git rm

• git show-branch

• git show-ref

• git show-ref --heads

• git show-ref --tags

• git stash save

• git subtree

• git taq --delete

• git tag --force

• git tag --sign

• git tag -f

• git tag -I

• git tag --verify

• git unpack-file

• git update-index

• git verify-pack

• git worktree

[as-if-and-only-if]

Git is a program that records changes to a repository (folder). You use git to initialize a specific folder as a git repository: this means git now stores and maintains all sorts of auxiliary data associated with that repository to remember the full history of changes to everything in that folder. (Actually, multiple histories, via branches. More later.)

The “way of recording changes” is constituted by particular conceptual components, and it’s these that you’ll be using git to modify and interact with. In a way, git is also these things, because, in a way, git is simply a program that helps you update and manage this data. So, here’s what those are:

The fundamental unit of this stored data is the commit, which is essentially a diff. A specific set of changes to specific files in the folder. Specific additions and deletions at specific locations. You get it.

These commits are organized into branches, so named because they actually can make a tree. Each branch is simply a linear history of commits (stretching back to the dawn of the repo. Note that it probably joins up with another branch at some point in the past).

You can of course have multiple branches in your repo: typically a “main branch” plus other branches you use for developing individual features.

Say you want to start working on adding the foo function: you make a branch named this_is_my_foo_branch, “checkout” that branch to say to git “this is what I’m currently working on”, start writing a bit/modify files, add your changes so far as a commit to that branch when it feels appropriate, write more, add another commit, etc.

Creating a commit is a deliberate act. Each commit has to have a descriptive message, and receives a unique identifying hash. Note that you can save files without committing the changes to them.

The other half of the story is the merge. To merge a branch into another branch, you take the commits in the branch you’re merging (which are diffs, changes) and apply them to the branch you’re merging it into. This doesn’t destroy either branch (it’a copy-like). If the diffs in one branch overlap with the diffs in the other, you may encounter a “merge conflict” and have to tell fit what exactly to do.

You may notice I’ve said very little about what commands to run. This is because either (1) it’s literally `git` followed by the name of the thing, e.g. `git commit` or (2) you will be using a nice UI wrapper to execute these commands instead of running them from the command line, e.g. VS code. (I recommend the latter if possible, as you can actually see everything you’re doing.)

Anyway, typically you merge for two reasons: either you merge a feature branch into the main branch to add the finished feature, or you merge the main branch into the feature branch to keep it up to date.

Aside: For the latter task you might sometimes “rebase onto the main branch” instead, which, instead of applying all the incoming main-branch commits on top of your branch, “rewrites history” and lifts all of your feature branch commits to lie on top of the most recent main branch commit. So if you care about having a clean history for whatever reason (sometimes people review commit by commit, or sometimes some automation demands it) you might want to rebase.

(You can of course merge and rebase any branch into/onto any other branch, it’s just less common to need to.)

GitHub is a platform for remotely storing git repositories and managing contributions to them from multiple people. It has a command line interface `gh` which can be useful when creating git repositories which you know you’ll be using with GitHub.

When you have a remote repository like this (the one stored by github), git also helps you sync the two repositories, via “pushing” and “pulling”. Pushing sends your local commits to the remote repository; pulling updates your local repository by, well, pulling the commits from the remote one.

On GitHub you can make a “pull request” from one branch to another, saying, “I request that you pull my changes from this branch into your branch”, but imo it’s more of a “merge request”. This is not part of git; only part of github. Only the merging itself if the PR is accepted is a git action.

(Aside: “Force pushes” overwrite history; normal pushes are “polite”. If you ever rebase, you need to force push.)

Hope this helps! I realize it’s a little light on “what buttons do i push”; I’d recommend going to github and following instructions, probably using gh instead of git directly to git started. (But this may well be anathema to purists.)

Miscellany:

One thing you might want to do sometimes is cherry pick a few commits from some other branch. It’s what it sounds like.

When creating a branch, you can initially base it off of whatever branch you like.

git log shows you past commits.

HEAD is, roughly, where you’re at.

If it detaches, something might be wrong, but apparently some people make use of this state. I don’t fully understand it, and while I’m usually the first to want to know how something works just for the sake of it, part of me hopes I won’t have to.

The “working tree” is where your saved-but-not-committed changes are.

git stash save and git stash apply let you save changes (and re-apply them later) on a specific branch without committing, so that you can e.g. switch branches and do something else then come back to it if you don’t want to commit just yet.

Files can be “tracked” or “untracked”. If you make a new file, it’s untracked until you add it.

.gitignore is a file specifying which files got should ignore.

You can “stage” uncommitted changes; only staged changes will be included in the next commit. Useful if you did a lot of work and want to split it up into several commits for review, or if only some of your work is commit-worthy and the rest is scratch.

rebase -i for “interactive” is quite useful, as it lets you modify past commits individually in a way it explains (edit messages, combine commits, delete commits…)

@~n refers to the commit n commits ago, e.g. got rebase -i @~2 will pull up a file that lets you guide what happens to the past two commits.

Alternatively, you can usually just supply the first five or so characters from the hash if you need to refer to the commit when talking to git.

Most systems come with some version of git already installed. But, it might be rather old.

Can someone explain to me in like five seconds how to use git, assuming that I know basic shit about coding/command line/whatever but don't know any of the specific terminology related to git. Like every tutorial online is at the same time both over my head and also vastly too basic. Just like. Tell me what it is.

Uh. First tell me its ontology. Is it a program, a standard, a language...? I know that it's for version control. Suppose I wanted to do version control at a piece of code. What do I do. What buttons do I press, on my computer? Tell me these things.

[mentalisttraceur-incomplete]

I have this weird habit of holding back on publishing a new code feature of there are improvements to related code which could easily be done either before or after.

For example, for basically a day, maybe closer to two now, I've had one of the most important remaining git-cotree features implemented:

git cotree --collapse <co-tree>

This "collapses" the given work tree's contents back into the repo root.

The typical case for me would be when I'm down to one work tree and I don't expect to have more than one for a while.

Another typical case would be getting people excited about git-cotree, both as a concept and to try it. Init is already really cool as a demo. Clone repo, make a bunch of changes, stage some

git cotree --init

and BAM, everything is now in the subfolder "main" (or "master" or whatever the repo's main branch is called); changes and index state and so on perfectly preserved. But if that wasn't cool enough? if you were hesitant to because what if you don't like the directory layout or workflow or whatever?

git cotree --collapse main

and BAAAM you're back to normal. You can delete the other co-trees first, or just let them hang around (but mind the collision risk - if you've got a file named "foo" in main and created a file/directory/cotree named "foo" in the repo root next to "main", the MVP of the collapse feature isn't protecting you against clobbering like that, and I'm not sure that in the general case it should ).

In practice, since so much test/build/etc code is written making dumb fragile hard-coded assumptions about relative paths, a third use-case would be to swap a worktree back into the "normal" position temporarily to run that stuff. git-cotree doesn't directly provide that complete swap experience, but cotree initialize and collapse handle the tricky and git-specific parts.

Anyway, despite having coded it, I've just been leaving it sitting in my local code, carefully working around it with `git add -p`, because I keep thinking of improvements that are relevant to both collapse and other stuff that's already published.

[colinkiama]

"git sweep" Alias - Delete All Local Branches Linked To Deleted Remote Branches With Just One Command!

I used to waste so much time deleting local and remote branches I was done with.

Now I just delete my remote branches (e.g. on GitHub) then run this command:

git sweep

and just like that, my local branches that track remote branches are automatically deleted!

Now let's go over how you can add this command...

What is "git sweep"?

"git sweep" is a git alias I created that is a shortcut that does the following:

Runs the "git fetch --prune" command to delete all references to remote branches.

Find local branches linked to deleted remote branches (these are marked as "gone") then deletes them.

Setting the alias

You can set it using the "git config" command or by editIng the git config file directly.

Here's the command to set the alias with the "git config" command:

git config --global alias.sweep "! git fetch -p && git for-each-ref --format '%(refname:short) %(upstream:track)' | awk '\$2 == \"[gone]\" {print \$1}' | xargs -r git branch -D"

Here's an example of what the config file should look like with the alias added:

[alias] sweep = ! "git fetch -p && git for-each-ref --format '%(refname:short) %(upstream:track)' | awk '$2 == \"[gone]\" {print $1}' | xargs -r git branch -D"

Conclusion

Check out Erik Schierboom's article on this to learn more about how all of this works in detail.

If you found this post useful in anyway, please like, repost and/or share it.

Thanks for reading!

[nextonesolutions]

Git: Mastering Version Control for Efficient Collaboration

Introduction

In the world of software development and collaborative projects, efficient version control is paramount. Enter Git, a revolutionary tool that has transformed the way developers manage code and collaborate on projects. In this article, we will delve deep into Git, from its fundamental concepts to its most advanced features, empowering you to harness the full potential of this essential tool.

Git: A Brief Overview

Git is a distributed version control system designed to track changes in source code during software development. Created by Linus Torvalds in 2005, Git has become the cornerstone of modern development workflows. Its decentralized architecture and robust features make it a preferred choice for both individual developers and large-scale teams.

Understanding Version Control

Version control allows developers to keep track of changes made to their codebase over time. It ensures a structured and organized approach to collaboration, making it easier to manage and merge code from multiple contributors. Git's distributed nature empowers developers to work on their own copies of the repository, contributing to a more seamless and efficient development process.

The Power of Git

Git brings several key benefits to the table: Efficient Collaboration: Git enables developers to work on the same project simultaneously without interfering with each other's code. History Tracking: It maintains a detailed history of changes, allowing developers to revisit previous versions and understand the evolution of the codebase. Branching and Merging: Git's branching mechanism allows for parallel development, and merging simplifies the integration of different branches. Code Review: Git's pull request feature facilitates code review, ensuring code quality before merging changes. Open Source Community: Git's open-source nature has led to a vibrant community that contributes to its continuous improvement. Git Basics: Setting Up To get started with Git, follow these steps: Installation Install Git on your system by downloading it from the official Git website or using package managers like apt or Homebrew. Configuration Configure your Git username and email using the following commands: bash Copy code git config --global user.name "Your Name" git config --global user.email "your@email.com"

Git Workflow A typical Git workflow involves the following stages:

1. Working Directory This is where you make changes to your files.

2. Staging Area Use git add to stage changes for commit. This allows you to selectively choose which changes to include in the next commit.

3. Commit Create a snapshot of the staged changes using git commit. This creates a new version in the repository's history.

4. Branching Branching is at the core of Git. Create a new branch using git branch <branch-name>. Switch to a branch using git checkout <branch-name>.

5. Merging Merge changes from one branch into another using git merge <branch-to-merge>.

Git Commands You Need to Know

Here are some essential Git commands every developer should be familiar with: git clone <repository-url> Clone a remote repository to your local machine. git status Check the status of your working directory and staged changes. git pull Fetch and merge changes from a remote repository to your local branch. git push Push your local changes to a remote repository. git log View the commit history of the current branch. git diff Compare the differences between files and commits. Advanced Git Features Git offers a range of advanced features to streamline your workflow: Git Hooks Hooks are scripts that Git can run before or after certain events. They allow you to automate tasks like running tests before a commit. Git Submodules Submodules allow you to include other repositories within your own. This is useful for managing dependencies. Git Rebase Rebasing allows you to modify the commit history by moving, combining, or deleting commits.

FAQs

How is Git different from other version control systems? Git is distributed, meaning every developer has their own local copy of the entire repository. This leads to greater flexibility and robustness compared to centralized systems.

Can Git be used for non-code files? Absolutely! While Git is popular in the software development realm, it can be used to version control any type of file, including documents, images, and configuration files.

Is Git suitable for large projects? Yes, Git's performance scales effectively with project size. However, Git's branching and merging strategies need to be well-defined for large projects to avoid confusion.

How do I resolve merge conflicts? Merge conflicts occur when Git can't automatically reconcile differences between commits. You'll need to manually edit the conflicting files, then commit the resolved changes.

Are there graphical interfaces for Git? Yes, several graphical user interfaces (GUIs) are available for Git, such as GitHub Desktop, Sourcetree, and GitKraken. These GUIs simplify Git's commands through visual interfaces.

How do I contribute to open-source projects using Git? Fork the project repository, create a new branch for your changes, make the necessary changes, commit them, push to your fork, and then create a pull request to the original repository.

Conclusion

Git has revolutionized the world of version control, empowering developers to collaborate seamlessly and manage projects with unprecedented efficiency. By mastering Git's commands and understanding its principles, you're equipped to excel in modern software development. Whether you're a solo developer or part of a large team, Git is an indispensable tool in your toolkit. If you'd like to explore more about Git and its advanced features, you can check out the official Git documentation for in-depth information. Remember, version control isn't just about managing code; it's about fostering collaboration and driving innovation. Embrace Git, and embark on a journey of code mastery and productive collaboration.

[thegnulinuxguy]

Recover deleted code files from Git repository

Tips to recover deleted code files from Git repository

Git is a decentralised version control system that works as content tracker for codes. It store project source codes of each developer who works in a project. It provides options to create/delete/modify files and folders, create/switch/remove branches and more in local repo and remote repo. The local repo is found on each developer’s local system. The remote repo is hosted on a central server…

[tastethelinux]

How to Delete GIT Branch Local and Remotely.

In this article, how to delete the branch in the local system, remotely using the git command. The issue faced while deleting the branches.

Introduction. This tutorial will cover “How to delete the GIT branch both in Local and Remotely”. But why delete the branch in Git? To develop any new features or fix the bugs in the repository we have to create a branch. And it’s a best practice to delete the branch when the branch is not in use. GIT is the Version control system used to manage the source code of an application. Where many…

[rehman-coding]

𝟏𝟎 𝐌𝐮𝐬𝐭-𝐊𝐧𝐨𝐰 𝐆𝐢𝐭 𝐂𝐨𝐦𝐦𝐚𝐧𝐝𝐬 𝐓𝐡𝐚𝐭 𝐚𝐫𝐞 𝐤𝐧𝐨𝐰𝐧 𝐛𝐲 𝐟𝐞𝐰𝐞𝐫 𝐩𝐞𝐨𝐩𝐥𝐞 (newbie). 𝟏. 𝐀𝐝𝐝/𝐂𝐨𝐦𝐦𝐢𝐭 𝐀𝐥𝐥 Standard way: git add . git commit -m "Message" Another way: git commit -a -m "Message" 𝟐. 𝐀𝐥𝐢𝐚𝐬𝐞𝐬 With aliases, you can write your own Git commands that do anything you want. Eg: git config --global alias.ac '!git add -A && git commit -m' (alias called ac, git add -A && git commit -m will do the full add and commit) 𝟑. 𝐑𝐞𝐯𝐞𝐫𝐭 The revert command simply allows us to undo any commit on the current branch. Eg: git revert 486bdb2 Another way: git revert HEAD (for recent commits) 𝟒. 𝐑𝐞𝐟𝐥𝐨𝐠 This command lets you easily see the recent commits, pulls, resets, pushes, etc on your local machine. Eg: git reflog 𝟓. 𝐏𝐫𝐞𝐭𝐭𝐲 𝐋𝐨𝐠𝐬 Gives you the ability to print out a pretty log of your commits/branches. Eg: git log --graph --decorate --oneline 𝟔. 𝐒𝐞𝐚𝐫𝐜𝐡𝐢𝐧𝐠 𝐋𝐨𝐠𝐬 One can also use the log command to search for specific changes in the code. Eg: git log -S "A promise in JavaScript is very similar" 𝟕. 𝐒𝐭𝐚𝐬𝐡 This command will stash (store them locally) all your code changes but does not actually commit them. Eg: git stash 𝟖. 𝐑𝐞𝐦𝐨𝐯𝐞 𝐃𝐞𝐚𝐝 𝐁𝐫𝐚𝐧𝐜𝐡𝐞𝐬 This command will delete all the tracking information for branches that are on your local machine that are not in the remote repository, but it does not delete your local branches. Eg: git remote update --prune 𝟗. 𝐁𝐢𝐬𝐞𝐜𝐭 For finding which commits caused certain bugs Eg: git bisect start git bisect bad git bisect good 48c86d6 𝟏𝟎. 𝐃𝐞𝐬𝐭𝐫𝐨𝐲 𝐋𝐨𝐜𝐚𝐥 𝐂𝐡𝐚𝐧𝐠𝐞𝐬 One can wipe out all changes on your local branch to exactly what is in the remote branch. Eg: git reset --hard origin/main 🚀 Follow @rehman_coding for more daily web development tips and tricks. #content #webdev #coding #css #webdevelopment #comment #contentcreation #devcontent #frontend #frontenddevelopment #HTML #Javascript #react #codewithcoffee #grid #codewithcoffeeindia #future #share #connections #like #css3 #csstip #html #htmltip #csslayout #cssgrid #grid #cssgrid #gridlayout #terminology Ruby, etc. (at I-8 Markaz Islamabad) https://www.instagram.com/p/Coo4IHtg9Wc/?igshid=NGJjMDIxMWI=

[mentalisttraceur-software]

Good news everyone! It gets worse (but almost invisibly/harmlessly so)!

It turns out that when you run commands like "git fetch" or "git pull", Git updates the... [I think "reflogs" is the proper term here] for the relevant remote branches. And I don't mean in the obvious way - it doesn't just pull down some identical copy of the information: it mutately some purely-local state in a way that's unique to that fetch.

So for example, if I have a local clone with just local branch "main" tracking "origin/main" ("origin" is the default name for the default remote), and I run "git pull" on one device, then I switch to another device, and run "git pull" over there before Syncthing finishes syncing that repo's directory, I get a Syncthing merge sync conflict in the file ".git/logs/refs/remotes/origin/main".

If my remote has more branches and my local clone knows about them, it's possible/probable that this could happen with multiple reflog files, one for each branch that has changes to pull down whose reflog files haven't synced yet.

The actually good news is that unlike the index sync conflict, which leaves you in a Wrong state, these remote branch reflog sync conflicts seem to be safe to ignore. They don't really do anything besides leaving junk copies of those reflog files in those directories, with Syncthing's distinctive sync-conflict file names.

The situation might be worse if you're using some other mechanism to sync your stuff. Syncthing's approach to sync conflicts is really nice here, because once it detects a sync conflict, it just leaves the original file with one version of the contents, creates a copy with the other version with a decently clear and unlikely-to-be-used-by-anything-else name right next to the original, and from then on, both files are basically synced like normal files - so if the one that ends up at the original name is fine then you can just ignore the situation, and you can resolve the sync conflict on any device with normal file operations (remove the sync-conflict-named copy, or delete the one at the original name and move that one over to the original name). But if your sync software somehow "jams" as soon as it detects a sync conflict until you manually resolve it, then this could get just as annoying as the situation with index files.

One frustrating edge case with Syncthing and Git to look out for:

Empirically, just based on observed behavior, it seems that Git has lots of commands that you'd think are read-only, but which in some cases will mutate internal Git state - specifically, the index (normally at ".git/index"). I haven't yet figured out if this can ever happen with other internal ".git" files.

This creates a race condition with any networked filesystem sync - if you do some work on a local checkout of a repo, then switch to another device to continue where you left off, you can't safely check if Syncthing has synced the local changes to the repo in the most intuitive way: by running commands like "git status".

You have to wait until you're sure the changes have synced, or you'll get a Syncthing merge conflict with the Git index file, which will manifest as weird/unexpected results from commands like "git status" and "git diff [--staged]".

(If you want to look more deeply into this, I'd probably start by reading and understanding Git's "Racy Git" documentation, which seems indirectly relevant - it's talking about a different race condition, but I wouldn't be surprised if the optimization which causes that race condition and/or any workaround which mitigates it contributes to this race condition.)

Luckily, it turns out that we can force Git to never mutate the index. With recent Git versions, there's a top-level "--no-optional-locks" flag that will do it: "git --no-option-locks status".

[ml-python-something]

GitShit 0x01

git clone https://name-of-repo # clones repository to local disk

git status # checks status of local repository Shows status of untracked

changes, new files, generally uncommitted changes.

git add file # start tracking changes of {file}

git add -A # starts tracking all of the files (except excluded in .gitignore)

git branch branch-name # creates a new branch

#Using branches many people can work in parallel on

the same project.

#Checkout is used to switching to different branches.

git checkout branch-name # switches to {branch-name}

git checkout -b branch-name # creates and switches to {branch-name}

# To merge branches you can use:

git checkout name-of-branch

git merge branch-name

# To view branches in project type:

git branch

# Deleting a branch is simple af just do:

git branch -d branch-name

git commit -m "name of commit" # commits a commit

git push remote branch-name # pushes changes to a remote repository

git push -u remote-name branch-name # uploads new local branch

git remote add remote-name https://name-of-repo # adds remote/source to pull

and/or push files

git revert {commit-number} # reverts a commit

# to obtain the number of a commit you can use

git log --oneline

[resetpermalik]

Recreating the Google Homepage

An Odin Project Challenge

Diversifying Education

Until recently, I have focused solely on building projects for freeCodeCamp. While these experiences are certainly valuable, I wanted to extend the reach of my education (while also teaching myself how to multitask with separate goals in mind.) This intention brought me to the Odin Project. Here, I have learned a bit of Git and have now completed a Google Webpage clone. The following will detail some lessons absorbed from this experience.

Git Basics(, very basically)

My knowledge of Git is still very minuscule. At this point, I am capable of cloning remote repositories to my local repository with ‘git clone (git@github.com:username/example.git)’.

Once the desired repository is within my target directory (and any adjustments have been made), ‘git add (file.ext)’ [track specific file] | ‘git add -A’ [track all changes] | ‘git add .’ [track new files and modifications without deletions] | ‘git add -u’ [track modifications and deletions without new files])’ will appropriately stage new, deleted or modified elements. This indicates a move from ‘working tree�� to ’staging area.’

After all of my intended files and folders are safely moved to the staging area, I am then prepared to commit to my local repository. This can be achieved by using the command ‘git commit -m “-insert-message-here-”’ [each message will document progress].

Intermittently, I am able to use ‘git status’ to ensure I know the current state of my elements within the working tree, staging area and local repository.

Lastly, when my information has been modified, moved from ‘working tree’ to ‘staging area’ and from ‘staging area’ to ‘local repo’… I then have the option of pushing all material to a remote repository (Git Hub) by way of ‘git push origin main’. This final command will tell Git (DVCS) to push the elements in question onward to the pre-set location (origin: declared previously with the cloned SSH key) and to do so on the (main) branch.

Finally, ‘git log’ will display pertinent info (in regard) to each of my commits. These distinctions are: unique commit hashes, author, date and messages.

I have integrated a few more Git tools into my workflow. I will quickly state those, but wait until I have a more balanced comprehension of Git before going into depth about functionality. They are as follows: ‘git fetch’ [retrieves references/objects only] | ‘git pull’ [retrieves references/objects and merges] | ‘git reset - -soft HEAD~1’ [undo last commit without altering recent modifications of current branch HEAD] | ‘git reset - -hard HEAD~1’ [undo last commit and recent modifications of current branch HEAD].

Any time I updated my ‘README.md’ file during this project, I used ‘vi’ (screen-oriented visual editor). The editor can be opened with the command: ‘vi file.ext’. In command mode: ‘i’ will allow insertion of text, ‘:w’ saves modifications, ‘:q’ exits the editor, ‘:wq’ concatenates both previous commands and ‘esc’ shifts from ‘edit’ back to ‘command mode’.

In addition, ‘touch (file.ext)’ [create a new file within the current directory] | ‘echo “-insert-string-here-” >/>> file.ext [replaces all text with new string/adds string onto next line in a file]’ | ‘sed ’s/find/replace/’ file.ext’ [find and replace certain characters/strings]’ | ‘sed -i -e ’s/-insert-string-here-//g’ [edit/remove certain characters/strings in-place]’ | ‘> file.ext then ^C’ [clear all text from file] | ‘(dquote) resolved with !’.

Coding the Webpage

The Google homepage is relatively simple to recreate (after having already demonstrating many requisite techniques in previous projects.) That said, I will share some new processes and maneuvers I learned over the course of this challenge which helped me deploy a more polished final result.

As I created my files for HTML, CSS and JavaScript, I added a ‘reset.css’ file with ‘Meyer CSS reset v2’. This removed all default browser styles and allowed for full control of any CSS I would later add.

Using pseudo-class selectors (hover and focus,) my anchors and buttons became more customizable. The instances where I used these allowed me to better dial into the signature Google-page-experience.

Two JavaScript events (onmousedown | onmouseup) enabled me to call functions which let me achieve the click behavior of my ‘sign-in’ button.

As a bonus to the development of this project, I learned how to better create textual images with  Photoshop. With attention to anti-aliasing, image size (width | height) and pixel density, I now understand how to implement smoother edges in these cases.

Conclusion

After completing this webpage, I am comfortable executing all I have learned until now. Of course, this is a small fraction of what is yet to come. However, I sense noticeable momentum and confidence after finishing this challenge. Now, onward to the next assignment.

[chiseld]

:/

I don’t know why I still have so much trouble with Git workflow. It seems so straight-forward, but I keep running into errors. Like just now, I finished working with a branch, committed and pushed it to its branch remote, then merged the branch back to master and deleted the branch.

At that point Git told me I was “ahead by 18 commits”, so I tried pushing again from the master branch, but got an error message saying I had to fetch new changes first. So I did “git pull”, but it told me “Already up-to-date!”

And when I checked my Git status, it now says I’m ahead of the origin by only 2 commits... :/ ??? I mean, I guess that’s an improvement. I can’t see any new code missing from the remote repo.

But just for the heck of it, I did “git push” AGAIN, got the expected results and was told “You’re up to date with origin/master now!” ...Although when I go look at the remote repo online, it says the last change was 16 minutes ago, although I did this last push just a few seconds ago. (And yes, I did refresh the page.)

Also, as I mentioned, I deleted the extra branch from the command line, but when I go look on GitHub it’s still there???

I really need a thorough course in Git workflow. Every source seems to tell me something different, and it’s just annoying >:(

ETA: I did a little Googling and discovered that local branches and remote branches are two completely different beasts and have to be deleted separately from each other. Oh well, okay, at least I’ve solved that issue now. (It does seem a bit odd, though...)

[scriptya]

Git and GitHub Commands

Git and GitHub Summary Notes

 1. Create a Folder with Files 

 2. Install Git  `git init` 

 3. To have a look at the stage area  `git status` 

 4. To add the file to the stage area `git add + filename` 

5. To commit the file under version control we use `git commit -m "message of the file"` 

 6. Actual Procedure when a password is required ``` git init git config user.name "someone" git config user.email "someone@someplace.com" git add + filename git commit -m "msg in present tense" ``` 

 Reference https://tecadmin.net/tutorial/git-tutorial/git-create-repository/ 

 7. To see the changes made after making some additions or deletions we use `git diff` 

 8. To return the changed file to the previous version we use `git checkout + filename` 

 Staging Area 

 Removing documents in the staging area - `git checkout + filename` after the `git add .` command 

 Un-Staging files `git rest HEAD + filename` 

 Deleting Files 

 `git restore <file>..."` to discard changes in working directory `git checkout`  to restore a deleted file from the folder To restore a deleted file with `git rm` we use 1. `git reset HEAD + filename` 

2. `git checkout + filename` To move everything to the staging area (changes and deletions) `git add --all` 

 Managing your log  

We use `git checkout + branch name` to change branches 

 To create a new branch we use `g`it branch + new branch name 

 To check out list of branches we use `git branch` 

To merge branches we use `git merge + branch to be merged` 

To rename a branch we use `git branch -m (org branch name) (new branch name)` 

To delete a branch we use `git branch -D +branchname` 

To switch to a hidden branch in github we use `git checkout -b (name of branch in git) (name of remote/name of branch in git)` ##### Grabbing all the github files 

 To create a mirror of all the branches from github we use `git clone --mirror (clone url) .git` 

To get all the files to appear on the folder `git config --bool core.bare false` 

To refresh the folder to get all the files `git reset --hard`

Using GitHub as a template 

Issue a remove command to remove all git log files to make the project a brand new project under your folder `rm -dfr .git` (be careful when using this command, its very dangerous!! lol)

To create a template we clear out any scripts or java-script files that we might not use 

 Then we issue a `git init` to officially make it your project 

 This will be followed by `git add .` then we commit  the template `git commit -m "new project"` to add the template to the log file 

GitHub 

 1. Create a new remote repository on GitHub with the local filename 

 2. Transfer command `git remote add origin (name of the remote) https://github.com/mrNicklaus/Poem.git (name of the branch)` 

 3. Push command `git push -u origin master` 

 Local Branching 

 1. To initialize branch `git branch + branch name` 

 2. To change branches `git checkout + branch name` 

3. To merge we return to the master branch to initialize the branch `git merge + branch name to be merged` 

 4. Remember to commit your changes before `git merge` 

5. After merge we push our changes to our local rep we use the command `git push -u rhyme(remote ) master (branch)`  

Remote Branching 

 https://github.com/mrNicklaus/Marvela/network 

 1. Create a new rep with a read me file 

2. Create a new file.txt 

3. Commit file after adding a description of the file.txt that you have just created 4. Create a branch from the master 

5. Inside the new branch edit changes in the file.txt 

6. Commit the changes to the new branch 

7. Create another file in the master branch and commit the changes 

 8. We use the term pull to merge two branches together, so we click on `New Pull request` 

9. Choose the base as the master and the compare as the new branch that was created 

10. Create Pull Request 

11. Merge Pull Request 

12. Add a message about the merge 

13. Confirm 

14. The merge has been performed successfully on GitHub /Remotely