{"id":18032358,"url":"https://github.com/dmitriz/git-collaboration-strategies","last_synced_at":"2026-02-19T11:32:21.692Z","repository":{"id":31010255,"uuid":"34568701","full_name":"dmitriz/git-collaboration-strategies","owner":"dmitriz","description":"Simplest and most effective Git strategies I know","archived":false,"fork":false,"pushed_at":"2015-04-27T07:25:44.000Z","size":848,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-10-24T16:32:14.520Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dmitriz.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-04-25T13:03:53.000Z","updated_at":"2017-01-16T20:07:10.000Z","dependencies_parsed_at":"2022-08-26T11:22:41.912Z","dependency_job_id":null,"html_url":"https://github.com/dmitriz/git-collaboration-strategies","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/dmitriz/git-collaboration-strategies","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dmitriz%2Fgit-collaboration-strategies","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dmitriz%2Fgit-collaboration-strategies/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dmitriz%2Fgit-collaboration-strategies/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dmitriz%2Fgit-collaboration-strategies/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dmitriz","download_url":"https://codeload.github.com/dmitriz/git-collaboration-strategies/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dmitriz%2Fgit-collaboration-strategies/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29611093,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-19T10:52:55.328Z","status":"ssl_error","status_checked_at":"2026-02-19T10:52:26.323Z","response_time":117,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-30T10:13:08.934Z","updated_at":"2026-02-19T11:32:21.672Z","avatar_url":"https://github.com/dmitriz.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"*I'm not doing this to \"teach\", I'm doing this to LEARN. Your feedback and corrections are absolutely welcome!*\n\n# Git Collaboration Strategies\nSimplest and most effective Git strategies that I know\n\n\n## Collaboration on a Project where you don't have push Privileges\n\nLet us say you like some project so much that you want to contribute to it. Or maybe you find it so broken that you want to fix it. More often then not, you can view and download files but cannot change anything. Speaking the language of [Git](http://git-scm.com/) - *you don't have push privileges* to the project.\n\nIf you are in this situation, you may find this strategy useful. I really like the project [AngularJS UI Bootstrap](https://github.com/angular-ui/bootstrap) and **will use it as example here**. If you are not used to Git of feel intimidated by it, you are at the right spot - I'll try to make it as easy and clear as I can.\n\n\n### Fork the project\n\nYour first step is to **fork** the project. Easy enough if you haven't forked it already a while ago. However, if you did, and your forked repository hadn't been updated with more recent changes for a while, **your existing forked repository will not be updated to the most recent changes just because you click on the \"fork\" button!** In fact, updating appears to be harder than it probably should be. Maybe to prevent folks to overwrite their own stuff, who knows...\n\n\n### Make sure your fork has exact copy of the original project\n\nMost likely you want to have the exact copy of the project as it is to get started with. Assuming you do, the simplest solution I found is the following *brutal one*, which **you have to use at your own risk**:\n\n- Just delete your previously existing forked repository and fork it again from the origin! That way you get the latest version and don't need any udpate.\n\nSo yes, the usual warnings and disclaimers apply, you can lose any work in that deleted repository, but really the same rules about backups (that you've doing already, have you?) apply to any work you do and store anywhere...\n\n\n### Clone your forked repository to your machine(s)\n\nIn my example I have forked the AngularJS UI Bootstrap project as https://github.com/dmitriz/bootstrap. In contrast to the original project, I have full privileges to my forked one. For instance, I can fully syncronize it with my local machnies, which I couldn't easily do with the original project. \n\nNow that we have our forked copy, we `clone` it to our local machine, speaking the language of Git. There are two ways:\n\n- Clicking the \"Clone in Desktop\" button on the main page of your fork, or\n- Running this command in local terminal:\n```\ngit clone https://github.com/dmitriz/bootstrap.git\n```\nFor the first to work, you'd need to install Github's desktop application on your machine, and for the second, you need to [install Git](http://git-scm.com/downloads), which you'll likely need anyway...\n\n\n### Make sure we have the most recent version on our machine\n\nWho knows, as you were busy forking and cloning, someone could have already sent a new update to the original project. So here is my first rule:\n\n- *Rule 1. I want my `master branch` to be clean at all times and reflect the latest changes as much as possible.*\n\nThat means, I never change anything there and try to update it regularly or whenever I need.\n\n*What is a branch?. It is common to give a long explanation [what a branch is](http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell). But in a real tiny nutshell - a branch is just a version of your code. It is like switching between directories containing different versions, except that Git does the switching for you in the same directory, and uses much less space for it.*\n\nAs you `cloned` your forked repository and entered its directory, you are (should be) in your local `master branch`. Here `master` is the common name for the main branch, which is like the main version of the code. Check that you are on `master` by\n```\n$ git status\n# On branch master\nnothing to commit, working directory clean\n```\nIt is often recommended to keep your `master branch` **deployable at any time**. In our situation we rely on the original project to be deployable, and simply try to syncronise it with the `upstream` at all times.\n\n*What is upstream?. Another buzzword - [see this StackOverflow thread for a long discussion](http://stackoverflow.com/questions/2739376/definition-of-downstream-and-upstream). Similar to a waterfall, where water is falling on you, with you having no control on it when standing below, Git's `upstream` is the original code that we can't influence directly.  In our example, `upstream` is the name (string) that is commonly used to point to our original repository. [A so-called Remote](http://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes) if speaking Git language.*\n\nLet us set our `upstream`, so Git will know where to get the updates:\n```\n$ git remote add upstream https://github.com/angular-ui/bootstrap\n```\nand check it with:\n```\n$ git remote -v\norigin\thttps://github.com/dmitriz/bootstrap.git (fetch)\norigin\thttps://github.com/dmitriz/bootstrap.git (push)\nupstream\thttps://github.com/angular-ui/bootstrap (fetch)\nupstream\thttps://github.com/angular-ui/bootstrap (push)\n```\nAnd now that we have set it, here is **my preferred and only command to update to most recent changes**:\n```\n$ git pull --rebase upstream master\nFrom https://github.com/angular-ui/bootstrap\n * branch            master     -\u003e FETCH_HEAD\nCurrent branch master is up to date.\n```\nHere `upstream master` means the `master branch` of the `upstream`, which is in our case the original project.\nThis one commands is doing a lot - it checks for all new changes in the `ustream` since you updated last time, downloads them and updates your `master branch` (or whatever branch you are currently in). If you observe my *Rule 1* and never make any changes to your `master branch` (other than updates), this should always work smoothly. \n\nIf, however, you've made some new local changes since your last update, the same command will try to do more for you - it will attempt to make all `upstream` changes **ahead of your new local changes**. And this is exactly how you want it - see below...\n\n*Note. The option `--rebase` is important. Without it, Git would try to download the recent changes and `merge` them into your local `branch`. It won't matter for your `master` (if you observe Rule 1), but would matter for other `branches` where you do make changes. And we want to keep our life sane by remembering just one command instead of 10. ;-)\n\n\n### Branch out and working\n\nNow the most interesting part begins!\nFinally we can work and do cool things!\nBut remember Rule 1 - don't mess with `master branch`.\nSo we first want to copy the `master` into a new `branch`:\n```\n$ git checkout -b new-branch\ngit checkout -b new\nSwitched to a new branch 'new'\n```\nThat's it! Now we can start working and mess around.\nEvery time you do a piece of work, it looks good, your tests pass etc, you should, again in Git's language, `commit` your changes:\n```\n$ git add .\n$ git commit -m \"name of my commit\"\n[new 59530bf] name of my commit\n1 file changed, 0 insertions(+), 0 deletions(-)\ncreate mode 100644 new\n```\n\n\n### Push to our forked repository\n\nFast forward, we worked hard and made something cool - a great addition to the project that we want to share with the world. First, we want to give it unique name, say `my-feature`, and move into a clean new `branch`:\n```\n$ git checkout -b my-feature\nSwitched to a new branch 'my-feature'\n```\nSecond, we have to make sure the world will accept it! And this is where my second Rule comes to help:\n\n*Rule 2. Always pull the latest changes from the original project before sharing your files*\n\nThis way we make sure our changes are always compatible with the world. And the great thing is - we can use exactly the same magic command:\n```\n$ git pull --rebase upstream master\n```\nHopefully, everything went well and we are ready to go. Hopefully, because ... what if meanwhile someone else made changes to the same files and uploaded to `upstream`? Or someone deleted a file we've been working on? Then we may end up with `rebase conflicts`:\n```\n...\nCONFLICT (modify/delete): brand-new-file deleted in server1 and modified in HEAD. Version HEAD of brand-new-file left in tree.\nFailed to merge in the changes.\n...\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase --abort\".\n```\nIf you see this for the first time - you get panick - don't! Should you make any mess, here is you rescue:\n```\ngit rebase --abort\n```\nNow we can restart again. But, unfortunately, if our changes are conflicting, we can't get around it.\nBut no worries - it is now our turn to decide the outcome! But we have to make the decision! In that case, we need to edit all affected files, `add` them to Git to keep track, and finally finish the `rebase`:\n```\n$ git add .\n$ git rebase --continue\nApplying: my-commit1\nApplying: my-commit2\n```\nIt is not necessary, but just to be sure we can run it again:\n```\ngit pull --rebase upstream master\nFrom https://github.com/dmitriz/fork-testing\n * branch            master     -\u003e FETCH_HEAD\nCurrent branch new is up to date.\n```\nPerfect! Everything is clean and we are ready to push our `branch my-feature` into a `branch` of our forked remote repository, for which I like to keep the same name:\n```\n$ git push origin my-feature\nCounting objects: 23, done.\nDelta compression using up to 8 threads.\nCompressing objects: 100% (21/21), done.\nWriting objects: 100% (21/21), 1.99 KiB, done.\nTotal 21 (delta 10), reused 0 (delta 0)\nTo https://github.com/dmitriz/bootstrap.git\n * [new branch]      my-feature -\u003e my-feature\n```\nThat looks really good!\nRemember that `origin` **does not** point to the orignal project (that is `upstream`!) but to our forked repository:\n```\n$ git remote -v\norigin\thttps://github.com/dmitriz/bootstrap.git (fetch)\norigin\thttps://github.com/dmitriz/bootstrap.git (push)\nupstream\thttps://github.com/angular-ui/bootstrap (fetch)\nupstream\thttps://github.com/angular-ui/bootstrap (push)\n```\n*Note. If you try to `push` from one `branch` to several different ones, Git won't let you. Which is too much trouble for me - that is why I always name both `branches` the same, so there won't be any two different remote for one local. Also `pushing` to existing `branches` can be a problem, so for small contributions I rather create brand new local `branch` and push it to the same named remote `branch` of the `origin`.\n\n### Finally - Pull Request!\n\nGo to your forked repository on `Github.com` and you should see the new button suggesting your to \"Compare \u0026 Pull Request\". That's it! If you did `pull --rebase` as recommended, it should let you submit it in no time!\n\nWell done!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdmitriz%2Fgit-collaboration-strategies","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdmitriz%2Fgit-collaboration-strategies","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdmitriz%2Fgit-collaboration-strategies/lists"}