I'm new to github and currently only starting off using github for mac.
I have taken a clone of my client's website and made some development changes locally. Note: I'm literally working with the files in the directory I sync with.
I want to push only one small change as the rest is still under development. Is it possible to push only the one file?
Git pushes deal with commits, not files. You'll need to create a commit that contains your selected changes. This is one area where Git's index is really handy.
Let's say you've modified two files, foo and bar.
If you want to commit only the changes to foo, using the command line you can do
git add foo
git commit
This will create a new commit updating foo, but bar's changes will remain only in your working copy. You can now push the new commit.
It's been a while since I've used the graphical GitHub tools, and I've only used them on Windows, but I believe the way to commit only certain files is to check or uncheck the box beside each file before you commit. You can see these checkboxes in their documentation:
You can go even further. If some of the changes in bar should be part of a commit, but not all of them, you can do something like git add --patch, which will break your changes up into chunks and prompt you for the ones to add to the index (these are the ones that will be included when you commit).
On GitHub for Mac you can do this too:
Select one or more lines to commit by clicking on the line numbers in the gutter. In the latest release, you can select a block of changes at a time. Hover over the right hand side of the line numbers to get a preview of what will be selected, and click to select.
See the documentation for git-add for details.
Related
I create a tutorial, where I want to introduce some testing frameworks like Mockito, WireMock and EasyMock. I want to explain it step by step. Additionaly I want to provide examples, where the reader of the tutorial can try to recreate these. Therefore I want to to give them the opportunity to look into my source code and use it when they are not able to recreate the test. And then they can use the actual version to continue and then again, when they are not able to create the next test, I want to to give them the possibility to use my new version with the new test.
My idea is to use different commits and link them to the tutorial. How can I do this or is there any better approach to reach what I just explained?
Easy Peasy!
The basic approach is this: browse to exactly what you want on GitHub, and then share the URL. GitHub URLs are stable permalinks, even when you navigate to an old revision or another branch.
Open the repo in Github.
Browse to Branch, tag or commit you want.
For branch/tag, there's a drop down in the upper left of the files listing.
For a specific commit:
Click on Commits at the top of the files listing. This will take you to a page showing all the diffs. (You can share this URL if you want. Otherwise continue to the next step.)
Clink on Browse files in the upper right corner.
You are now looking at a repository view just like the one where you started, except this view is of a specific branch, tag or commit. It's like a GitHub time machine.
If you want to link to the entire repo at this branch/tag/commit, copy the URL right now.
If you want to link to a particular file at this branch/tag/commit, navigate to the file in the listing, then copy that URL.
If you want to link to a particular line in the file, click on a line number, then click on the ... button that appears next to it and then click Copy permalink
If you want to link to a range of lines in the file, hold down the shift key and clink on the other end of the range of lines. The lines will be highlighted. Click on the ... button that appears next to it and then click Copy permalink
All that said, unless you are walking them through your many iterations of the code, I'm not sure giving them links to versions in git history is the way to go. Let's say they want to clone your repo. Then they'd have to git checkout example-2-version-3 or something.
The more typical approach is to put the different versions in a directory hierarchy, making it far easier to browse, whether on GitHub or a local clone of your repo.
I'm fairly new to programming and thought I'd try out version control. I created a GitHub account to help me track my journey of creating my first webpage.
I want to upload updated versions of my code as I go along (e.g. Stage1, then perhaps when I progress a little further Stage2, then Stage 3 etc). This would essentially be the same file of code but each time it will be added to/ edited slightly.
Could someone advise me as to how to do this?
Thank you! :)
Every commit you push to your repository is stored and then you can access every version that you have committed afterward.
Just go into your repo, click at your commits tab:
Commits Tab
Then you can access the version by clicking the commit hash you desire to browse:
Commit hash abbreviated
After this, you just click in browse files.
If you want to use in your computer another version, you just have to git checkout 'commit hash' inside your folder at sync with your git repo.
It is possible in GitKraken to revert changes of a single file to an earlier commit instead of reverting an entire commit?
Answer
A revert in the git-sense of it can only be performed on a commit. It introduces a new commit that exactly negates the reverted commits' changes. See here. GitKraken supports this: right click on a commit, Revert <branch> to this commit.
What you want to accomplish, however, can be done via git checkout. I do not think GitKraken supports this funtionality for a single file yet. You can, however, use the command line.
Reset single file via command line
git checkout <commit> <file>
Check out a previous version of a file. This turns the <file> that
resides in the working directory into an exact copy of the one from
<commit> and adds it to the staging area.
Documentation can be found here.
git checkout HEAD~1 <filename> will thus reset a single file to the commit before the current HEAD.
You can accomplish this in the GitKraken UI, but it's a little roundabout:
Revert the most recent commit(s) back to where the file was deleted, but when GitKraken asks if you want to immediately commit the reversion, click no.
Unstage all changes
Stage only the add for the file you're trying to restore
Right click in Unstaged, and Discard all
This should leave you with only an add for the one file you wanted to restore. Commit that, and now you've got your one file back.
Note that this can work across numerous commits, not just one... but since it's going to have to roll back everything from all of those commits, and then discard all of the rollbacks (except one) it can be quite slow if involves massive changes. In situations like this, it is probably better to use the git CI as suggested in kowsky's answer.
Although it doesn't strictly involves using git commands, GitKraken offers the possibility to visualize the content of any project file at any given commit.
When acting on a single file, it might be much easier to copy/paste the targeted commit file's content than using complicated git commands that might very well end up messing your whole project's commit history.
To achieve this, simply:
Open your git project in GitKraken
Click on the desired commit in the commit history line
In the right panel, check the View all files checkbox
Locate the desired project file and click on it
The file content will be displayed in the main panel
You can now copy/paste the content
Simple and efficient when you only need to revert a very limited number of files...
GitKraken 7.3.0 (probably older versions too) does allow for effectively running git checkout on a single file in the UI: Right click on the file under "unstaged files" and select "discard changes". Works on folders as well.
(This answer was previously a comment to the accepted answer)
You can make an UNDO to the last commit edit it and after that make a Force push to overwrite that. Works very well
Hope GitKraken can do this, as "TortoiseGit" does.
I started using SourceTree few days ago and after I committed and pushed my changes to the remote GitHub repository, the numbers on the buttons remain the same, for example if the number on the push button becomes 3 when I committed a change, after I pushed it; it needs to be 0 or empty. But that's not the case here, it remains the same even though it has successfully been pushed. I also checked that my changes had been pushed using a web browser by going to the GitHub site. Is it because of the branch that I have pulled from and am pushing to are different or something else? Can any one please help cause I don't understand it... Thanks!
The numbers shown on the right hand side of the Branches panel reflect how many commits ahead or behind the Tracking Branch you currently are. If the numbers aren't what you expect, you should verify that the branch is tracking what you actually want.
You can verify the tracking branch by right clicking your local branch (as depicted below) and expanding the Track remote branch menu item. Finally, if you want to change the tracking branch simply click the new target from the list and Sourcetree will update accordingly. Hopefully that helps make sense of the disconnect that can happen when you rename branches and provides some details around why it happens and a simple way to resolve.
The same thing also happened to me too, I was working on branch I had push everting but was keeping appearing one unsend Push and miraculously also appear unsend Push on Master.
So what did was the same as Hristo Staykov and Sammie remove the Master branch from my local computer, since I had one miraculously unsend Push on Master did need to run this line terminal to remove the branch:
git branch -D master
And then Repository > Refresh Remote Status
I simply use the keyboard shortcut from the Repository menu:
CTRL+ALT+R (or control+option+R if you prefer)
My guess is that the shortcut would be the same or at least similar on Windows. Just look for the option called Refresh Remote Status under the Repository menu.
I am working in a small organisation, only two developers and we use Mercurial version control tortoisehg-2.2.2-hg-2.0.2-x86. I am new to mercurial.
Consider programmerA, programmerB.
In programerA machine I created a repository and a client with name "EFSL".
programmerB is simply a client with name "Uthaya Kumar" pointing at programmerA machine repository.
When I am pulling change set in programmerA machine it creates a new branch,
and it also shows "Not a head revision!" error in both working directory and repository.
In programmerB it is fine.
Please see the screenshots below.
Thanks in advance.
Examine the first screen shot and see that the top line says 8+ in the Rev column. This means that your working copy is based off revision 8. You can follow the line down and also see that it joins at revision 8 which indicates the same thing.
There are two ways to solve this depending upon whether you have made any changes or not.
If you have not made any changes then you would right click on revision 13 and select Update.... to update to the latest change.
If you have made changes then you need to commit those changes and then right click on revision 13 and select Merge with local... which brings up a wizard to handle the merge.
In your last screenshot it seems like you've not got a working copy at all so you need to use the update procedure above to update to revision 13.
You can have the update happen automatically by changing a setting in TortoiseHg:
Select File > Settings from the Workbench
Choose where you want to make the setting change by selecting the appropriate tab at the top. The choices are global to the user or just for this repository
Select Workbench in the left list
In the section on the right, look for a drop down list labeled After Pull Operation
Select update from the list
This will do an update to latest every time you do a pull which will avoid the problem in your first screenshot. You will still have to do a manual merge when you and another developer have made changes.
The other options in that list are rebase and fetch which both rely on the appropriate extension being enabled and are for advanced use only.
This is perfectly normal and correct behavior of Mercurial. Your working directory is currently updated to changeset 8 "Merge 2". The pull operation will not change the contents of your working directory. It simply gets missing changesets and adds them to your history graph. After pulling you are still working on changeset 8. Now the "Not a head revision" appears to warn you, that if you now make any changes and commit them, you will create a new changeset derived from Revision 8, which will effectively create a new branch. This is something you may or may not want to do. Typically after pulling new changesets, you want to update your working directory to the latest changeset, by right-clicking the latest changeset and choosing Update...
P.S.
Your are not using the latest verion of TortoiseHG. Please update to the latest version. It contains many improvements and resolves many bugs.