Even if you have commit permissions and will be pushing yourĬhanges to the main git repository yourself, you can still squashĬommits together later via git rebase before merging into the Because git branches are cheap and easy to throwĪway, you don't need to be careful about crafting one tidyĬommit. Particularly if you are doing the same fix to multiple branches.Īt this point, you can add, modify, and remove files and commit as often as you like. You might want to include the base branch name as well, Replace branch_name by something descriptive, e.g. Create and switch to a new, local branch by running Things the typical git way, you’re going to want to create localĪfter cloning, change to the branch you want to base your work Work on more than one patch at a time, or if you just want to do If you are intending to do any complicated changes, or if you want to The Better Way: Local development branches You can then upload "patch.diff" as your patch. Recording changes to the git repository for more details. You’ll have to add -cached to the git diff command. Tell git about any other changes you want to commit as well. "staged" changes to be committed (added your new files), you have to You’ll also have to run git add on any modified files and If you want new files included in your patch, Really wanted to add them or if they are just left over from somethingĮlse, e.g. This will not catch any new files, since git doesn’t know if you If you’ve only modified or removed existing files, then this is all you need: Only be used if you’re making simple modifications to a couple files Modifications and use git diff in that branch. The simplest way to generate a diff is to just make local The Simple Way: Local uncommitted changesĪfter cloning the Bugzilla repo and switching to your desired branch, The following sections outline some simple workflows for furtherĭetails, see the Pro Git book or any of the numerous tutorials and Git is very powerful, but anything beyond simple use is greatly aidedīy an understanding of the whole system. This is the preferred way of making patches. Basic usage is very similar to bzr, but there are differentĬoncepts and workflows. We are transitioning to git for our sourceĬontrol. 2.2 If Your Patch Contains Renames: bzr bundle.1.2 The Better Way: Local development branches.1.1 The Simple Way: Local uncommitted changes.will usually be master, unless you are applying a security or other crucial fix to an older branch.Īfter the push successfully completes, paste the output into the bug as a new comment and resolve it FIXED. will be origin if you cloned directly from ssh or used set-url otherwise it will be the name you gave to git remote add. Git remote set-url -push origin you ever need to set up a new local repo, you can just clone it directly: Git remote add or if you originally cloned from https Assuming you have already cloned it via the read-only https protocol, you can either add a new remote or update an existing remote: Once you've committed or merged to the right branch (usually master) of your local clone, you are ready to push it to Github. If you are committing the patch on behalf of someone else, such as a contributor without write access, use the -author option to "git commit" to indicate this, e.g. For example, of the summary of the bug is "Bugzilla doesn't do Foo", then your description in the commit comment should say something like "Make Bugzilla do Foo". Note that the description given on the commit comment should describe what the patch actually does (in a broad sense), which may not necessarily match the summary of the bug being fixed. a= indicates the person who approved it for check-in. r= indicates the person(s) who reviewed your patch. $ git config -global user.email pushing, make sure your commit message is of the form $ git config -global user.name "John Doe" Make sure you've identified yourself via git config. ( Note: If you are already a Mozilla Committer and you just need Git access, just file a bug in this component requesting it and CC one of the Bugzilla leads.) Your bug should be filed in the Repository Account Requests component. For Bugzilla, the requirement is that one of the Assistant Project Leads or the Project Lead vouch for you. To gain commit rights, you'll need to become a Mozilla Committer. These instructions are specific to the core Bugzilla repository but also apply, suitably modified, to other Bugzilla-related repos. Bugzilla follows a centralized work flow all commits must be pushed to Github. As of July 2016, the repositories of record for Bugzilla are on Github.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |