-
Notifications
You must be signed in to change notification settings - Fork 1
Helpful Git Commands
In the VBAToolkit repository, the publication branch is an orphan one. This means that there is no parent relationship between publication and other branches, including master. So the publication branch may stay simple. publication and master are both tagged with publication version numbers. The publication branch contains the VBAToolKit.xlam in the Delivery folder, and Documentation in the dedicated folder. Images for the Wiki are in the Images subfolder of Documentation folder.
An orphan branch was created with the command git checkout --orphan publication.
It is recommended to frequently synchronize your work with the master branch of the parent remote repository. Assuming that you created your own fork of VBAToolkit on GitHub, then cloned your fork locally on your system, and assuming you are working on a branch name current-work. The first thing to do is to declare the parent repository, for example under the name upstream: git remote add upstream https://github.com/jpimbert/VBAToolKit.git. Then you can synchronize your work with the master branch of the parent remote repository. Do it each time this master branch is modified:
- Complete your current incremental work and commit on the current-work branch and change your working space for your master branch with
git checkout master - Synchronize your master branch with the parent remote repository with
git fetch upstreamthengit merge upstream/master. Normally there is no or very few conflicts at this step (your master branch does not have to be a working branch, just a replicate of the parent remote master). - Return your working space to your working branch with
git checkout current-work - Merge the master branch to your current work in order to complete it with the last up-to-date version of the code:
git merge master - Complete the merge: recreate the Excel files with the merged source modules
- Resolve the conflicts: fix the conflicted modules in the Excel project then re-export the modules.
- Run all the Tests to finalize the conflict resolution, then Commit to inform Git that the conflicts were resolved.
Recommandations:
- don't wait to synchronize. Frequent synchronization is less work to do.
If you are working on a branch, and you want to commit your local modifications to another branch, you can switch to this new branch and simultaneously merge your local modifications in it with git checkout --merge <new-branch>. This way your modifications will be applied to the branch <new-branch>.
Another problem is to temporarily checkout to another existing branch but keep somewhere your current modifications that are not ready to be committed in your current branch. You can use the stash on your <current-branch>.
git stash
git checkout <another-branch>
------ Work on another branch
git checkout <current-branch>
git stash pop
git checkout <branch> -- <filePath>
- Clone the project to local directory if he don't exist , ou if you have a problem with git GUI.
- choose the 'sha' commit that you wanna to delete it .
- tape this command ##
git revert sha -n - +- the update will be maded on local repository.
- push code to server ##
git push - commit change ##
git comit -m 'the message without space' -a
-
git statusto get change maded -
git commit -m "message without space" -acommit change and index files -
git pushpublish the new version
git reset --hard HEAD~1git push -f
To follow a work performed on another remote which is a fork of the origin repository, we must declare the fork remote in our local repository and optionally create a branch if we want to commit our modifications: git remote [-t <branch>] add <name> <url>. <name> is the local name of the tracked remote repository, choose it at your convenience. <url> is the URL of the tracked remote repository. <branch> is the name of the branch created for the remote master branch tracking.
To follow and work on another branch of the same remote: git checkout -b \<new-branch\> \<name\>/\<branch-to-follow\>