Hi @anasustic
The changes look good to me! :confetti_ball:
I was searching why \ No newline at end of file is reported and came across this. Could you please add a new line at the eof?

Also, just a reminder, you might wanna rebase/squash your commits to resolve conflicts :)

Hi @shraddhaag Thanks :raised_hands: I rebased/squashed my commits. I believe I am now up to date with upstream/master :blush:

@anasustic seems like there are still merge conflicts. Here are some helpful resources to help you get the job done:

1. You can refer this while you rebase and then squash your commits.
2. If during rebase you encounter a merge conflict, this can be helpful.

Hi @shraddhaag. I believe I am up to date now with the commits :blush:

@anasustic Great job done! :confetti_ball:
Just one tiny thing, could you please also squash these commits into one commit? It becomes easy to merge that way. Here is a helpful guide for the same :)

Hi @shraddhaag I am not sure anymore :sweat_smile: but when I run git rebase -i master the rebase I get Successfully rebased and updated refs/heads/master

@anasustic Oh! You've made all your changes on the master branch. What you've done here is merge all the commits that you got from upstream into your commit.

What you want to do now is rollback the previous rebase you did. You should do that following this.

Hi @anasustic, thanks for the PR! :raised_hands:

Looks like the PR fell out of sync with the master branch. It is hard to review because the files changed shows other files not changed by you, but by others in already-merged pull requests. This happens when new commits are added to the original project after you make your commits.

The best way to avoid this is using the feature branch workflow. This is an effective way to use git when you are working on a project with others. It is helpful when changes may be merged while you are working on changes. Feature branches make it easy to "replay" your changes on top of the latest changes in the master branch of a project.

Once you use a feature branch, you need to rebase on top of master branch like @shraddhaag mentioned. git merge and git rebase are two different methods. Using git merge pulls all changes from one branch and puts them on top of the project, after your changes. It creates a merge commit like in this PR. Using git rebase is like a card deck, where your cards (commits) are pulled out and placed on top of the other cards (commits). This does not create a merge commit, but may create a merge conflict which you have to solve by manually editing the files with a conflict.

You can see these two guides I recommend for learning how to rebase:

• Don't Be Scared of git rebase
• How to Rebase a Pull Request

I hope this explanation is helpful. This was something I didn't learn for a while until after using git. When you rebase this pull request, it will be able to review your changes. :grinning:

@anasustic Hi if want git to not save commits or history of other branch files to your current branch file, you can do this.

git checkout master and git pull origin master #this is to pull the changes in the upstream
git checkout -b < your branch >

To correct your mistake, you can do:

git rebase --onto master < previous branch > < current branch >

Also if you are not familiar about git rebase, there is simpler way to do it to squash your commit into one.

git reset $(git merge-base master branch-name) *don't remove the $sign. paste it the way it is

git push —force origin branch-name.

Hi @jflory7, I rebased but had some issues with the two conflicts I ran into while merging. I tried to revert back to a previous commit but that didn't help either. I think I need some assistance :sweat_smile: to clean this pull request.
Thanks :smile:

Hi @anasustic
Okk, let's see what you did.

Firstly, what error are you getting currently..???

Hi @phoenix1796 I am not getting an error. I should have only my admin.py in the pull requests (under files changed). Instead I have two other files (the two files I got errors in the rebase and I had to resolve conflicts).

Okk...
So as I can see, There are two other files that you have not worked on, and your actual file admin.py is missing.

And these changes occured after you rebased right?

What I think can help you is copy the file contents directly from the main repo and paste it in your local files. This should help resolve any conflicts.

P.S. You tagged the wrong 'phoenix' :sweat_smile: :sweat_smile: :sweat_smile: :sweat_smile: :sweat_smile:

Sorry @phoenixabhishek for tagging you and thanks for your reply :smile:
Yes I have the two files in my change that should not be part of the change and the admin.py missing after reverting back to previous commits.

So assuming that the upstream is set in your local system,
can you try to git fetch upstream followed by git merge upstream/master

@anasustic Hi! Give these a try maybe?
1. git reflog and locate the last known good change that you want to revert back to, lets assume that's HEAD@{3} for this scope.
2. git reset HEAD@{3} --hard This will point the head to the last known good change you want to revert back to. [Be sure to replace the number inside {} with the one you found in step 1]
3. Then update the master using
git fetch upstream
git merge upstream/master
4. Create a new branch. [This is strongly recommended as @jflory7 explained]
5. Switch to the new branch using git checkout insertNameOfNewBranch
6. Make the changes (Add your admin.py file :blush: )
7. Commit those changes
8. Again, repeat step 3 to make sure your master is up to date and then rebase your changes.
9. Finally push those changes and you're good to go!

Hope that is easy to follow and helps understanding the flow better :)

Hi All. Thanks for all your suggestions. I have applied them in #194 Add django admin.py. Please take a look when you have a moment.

Hi All. Thanks for all your suggestions. I have applied them in #194 Add django admin.py. Please take a look when you have a moment.

Thanks, I left a comment there. :thumbsup: I will close this PR as a duplicate of #194.