-
Notifications
You must be signed in to change notification settings - Fork 45
Helpful Git Commands
When there is #<IssueNb> (with blank before and after and without < and >, for example #5) in the Title of a Commit, a comment with the same message as the commit is automatically added by GitHub and attached to the issue with the same number.
Be careful with mergetool utilities. Some of same may change the end of line characters (Unix convention vs Windows convention) and the source file produced could be corrupted from a Windows perspective.
We can use WinMerge to visually edit a git diff file.
git checkout --ours <file> will keep our local file when merging from another branch.
git checkout --theirs <file> will keep the file from the other branch.
When there is a conflict with a binary file, the local file is kept in the working directory, use git checkout --theirs <file> to keep the file from the other branch.
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.
In order to keep the commit network as simpler as possible, it is recommended to:
- Use Merge when pushing a completed work from a branch to the master branch. The commit chains of both branches are kept un changed, a new commit is added for the merge.
- Use Rebase when pulling the master branch to a branch for a work in progress. The commit chain of the master branch is unchanged, and the commit chain of the working branch is completely rewritten to start at the head of the master branch
To do a rebase type:
git checkout master
git pull ' get the last commit from remote repository
git checkout myWork
git rebase master
The rebase process can take a while. Since each commit is rebuilt, some conflicts may appear. You have to resolve them reindex the files modified and type git rebase --continue to continue the rebase process. You can abort the whole process with git rebase --abort or skip a specific commit with git rebase --skip.
Caution Avoid to rebase when binary files are involved in the commits to rebase.
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 -b <new-branch>. This way your modifications will be applied to the branch <new-branch> (-b option is mandatory to create a 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>
We have to be on another branch to do this
git branch -f <branch> <commit-number>`
git push -f origin <branch>`
- 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 remote prune originpropagate the branch deletion from the remote origin to the local repository
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\>