Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- # How To Contribute To A Group Project (And Get Your Brain Around Git & GitHub)
- Fork
- Clone
- Push
- Send a Pull Request
- Pull the updates
- You can clone the group repo directly but forking first makes it easier to set up remote links
- [tips] its fine to pull if CYF has no updates to pull in.
- For the quick ver here’s the bare instructions…
- Setup and initialisation:
- Find the GitHub repo to contribute to
- Fork it to your account
- Clone it to your machine
- Edit it, commit the changes, push them to your remote.
- Submit a pull request to the admin. They accept.
- Workflow:
- Add a remote to the group repo from your local
- Pull from the group repo when it’s updated by group members. Continue maintenance!
- Git is a version control system, it's a command line application but there are GUI clients for it. It tracks changes to text files in your project so you can revert to an older version.
- Git and GitHhub have their own terminology so it can be confusing for newcomers e.g. repo is “project”
- Check if you have Git `git help`
- As normal you create a project folder. To track it you “initialise” Git into the folder.
- You can chuck your project files on any old website, but GitHub allows collaboration, shows more project details, and promotes openness.
- Make a GitHub account (it’s built into FreeCodeCamp’s steps!)
- ,
- What helps me understand the names for actions are 3 kinds of barriers: location (off/online), time (first/repeat), permission (between accounts)
- The first time you upload a project it has a special term “add a remote” (not a snappy name), this connects your offline proj to the online copy of the proj for continuous updating and it’s 2-way. The world can see your proj. But now you’ve changed the offline version, the remote is out of date or “behind”. To update it you push changes to remote. Hence the barrier of local > remote is overcome with a push.
- This ends the single player mode. ...or it would. Did you notice I said 2-way? To receive changes you pull from remote to local but no point
- So my pal has a GH account, has a calculator proj but I noticed a mistake I can correct. I cant edit his directly as I dont have permission. But I can get a copy to make my own. Fork is a special kind of pull across the barrier of permission. The other direction has a name I’ll cover later.
- That was the setup so some actions get unique names for the first times they’re used. For your continual workflow different names are used in the cycle because the actions repeat.
- Recap:
- Local - initialise
- Local > remote - add remote (1st)
- Local > remote - push (cont)
- Group > remote - fork (1st)
- Remote > local - clone (1st)
- Remote > group - pull request (1st+cont)
- Group > local - pull (cont)
- Group > local - clone (1st)
- Remote - create? (I do it)
- Group > remote - reverse pull request? (dont)
- Remote > local - pull (dont)
- Local > group - ...you cant
- location (off/online), time (first/repeat), permission (between accounts)
- Warnings + inefficiencies:
- Remember the “commit -m ‘ ‘ ” in commits, or you’ll get stuck in vim. can change default editor to nano
- You can rebase but in a non-production repo why hide your decisions?
- You can pull from your own remote but why? It’d mean you used GH’s editors so don’t, or that you’ve been hacked, also dont.
- You can clone the group repo to local and then add a remote to your own account to pull request ...but then I couldn’t have introduced forks ;)
- Dont worry about accepting pull requests unless you’re confident enough to admin an open source project ;) You can reject them all but ppl can still fork it cos GH promotes sharing
- Pull requests need permission every time but submitting one the first time obviously doesnt create anything. Not without hacking ;)
- “hello contributors! Thanks for taking an interest in getting involved. If you're new to Git, GitHub, and collaborating then here are some tips.
- Git is a VCS so you can undo mistakes.
- GitHub is just a website that hosts projects or “repos” with some fancy features that makes it work well with Git.
- Git works on your computer (locally) so that's where most of the work gets done before you upload or “push” it to GitHub so it becomes a “remote repo”.
- Now you have a publicly visible repo up on GitHub and only you have permission to edit it. You can keep adding changes to the project and then regularly push updates to GitHub in a one-way workflow.
- What if you see someone else’s project and want to help? You can send them a suggestion or “pull request”, if they like it they'll accept and merge the changes. You can receive feedback from the administrator(s) on your suggestions.
- What if the repo is updated by other people and your fork becomes out of date? Then “pull” the updates
- (you can “pull” to your “fork” in a “reverse pull request” but that's gnarly bro)
- Fork, then on your fork press “new PR” and the ”base” is what you're aiming for GCC, the “head” is yours
- Pitfalls
- [updt-ish] Git+GH things you arent meant to do but can:
- You can but don’t use GH’s online editor. It puts your remote ahead of your local (which needs pulled and you might get confused). And anyway what else did you get a fancy IDE for??
- You can but don’t pull from your own remote, it means you edited online, did a reverse-PR, or accepted a PR. ‘Publishing’ should be one-way;
- You can but don’t do a ‘reverse Pull Request’ to update a fork online (it’s like a pull across remote repos)
- You can but don’t commit directly to master. You’re meant to branch and merge when it’s mature enough
- I like to create a new repo on GH first and thten clone to local because it skips the step of adding a remote ...but tutorials say start local with “git init”, create blank on GH and add remote.
- You can avoid configuring Git with your username+email on another machine and push to GH. But GH then shows commits were made by an “unregistered GH user” using the default credentials from the machine.
- [updt...] Git+GH’s odd terminology:
- “repositories” should be ‘projects’
- “pull requests” should be called ‘suggestions’ or ‘contributions’
- “origin” and “upstream” should be ‘upload’ ‘download’;
- “base” and “head” branches should be “target” and “offering” branches;
- A repo being both “ahead” and “behind” at once sounds odd ...but no alternative
- Commits are encrypted with SH4 “hash”
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement